Ubuntu 26.04 設定反映の確認 – reload / restart / daemon-reload を切り分ける

Ubuntu 26.04 で設定を変更した後は、その設定がどの仕組みに読み込まれるのかを切り分けて確認します。サービス設定なら reload や restart、systemd unit なら daemon-reload、sysctl なら sysctl -p、GRUB なら update-grub と再起動が必要です。

この記事では、設定変更後に何を実行すれば反映されるのか、どのコマンドで反映済みか確認するのかを整理します。やみくもに再起動するのではなく、設定の種類ごとに反映単位を分けることが目的です。

最初に切り分けること

• アプリケーションやデーモンの設定ファイルか。
• systemd unit ファイルや drop-in を変更したのか。
• カーネルパラメータやモジュールの設定か。
• GRUB や fstab のように再起動後の確認が必要な設定か。
• 反映後に確認すべき実行状態やログが何か。

サービス設定の reload と restart

reload はプロセスを維持したまま設定を読み直す操作です。restart はプロセスを停止して起動し直す操作です。サービスが reload に対応していない場合は restart が必要です。

systemctl reload nginx.service
systemctl status nginx.service --no-pager
journalctl -u nginx.service -n 50 --no-pager

systemctl restart nginx.service
systemctl status nginx.service --no-pager
journalctl -u nginx.service -n 50 --no-pager

reload 対応を確認する

reload が使えるかどうかは unit の定義やサービス実装に依存します。ExecReload があるか、実行して失敗しないかを確認します。

systemctl cat nginx.service
systemctl show nginx.service -p ExecReload
systemctl reload nginx.service

systemd unit を変更した場合

unit ファイルや drop-in を変更した場合は、サービスを再起動する前に systemctl daemon-reload が必要です。daemon-reload は systemd manager に unit 定義を読み直させる操作で、サービスプロセス自体の再起動ではありません。

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl status example.service --no-pager

drop-in の確認

drop-in を使った場合は、最終的な unit 定義を systemctl cat で確認します。想定した override が読み込まれているかを見ます。

systemctl cat example.service
systemctl show example.service -p FragmentPath -p DropInPaths

sysctl 設定を反映する

/etc/sysctl.d/*.conf を変更した場合は、対象ファイルを指定した sysctl -p か、全体を読み込む sysctl --system を使います。反映後は実際の値を sysctl で確認します。

sudo sysctl -p /etc/sysctl.d/90-my.conf
sysctl net.ipv4.ip_forward
sudo sysctl --system

カーネルモジュール設定を反映する

/etc/modules-load.d/*.conf は起動時読み込みの設定です。今すぐ読み込む場合は modprobe、設定ファイルを読み直す場合は systemd-modules-load.service を確認します。

sudo modprobe br_netfilter
sudo systemctl restart systemd-modules-load.service
lsmod | grep br_netfilter
systemctl status systemd-modules-load.service --no-pager

fstab の変更を確認する

/etc/fstab を変更した場合は、再起動前に findmnt --verify と手動マウントで確認します。いきなり再起動すると、起動時のマウント失敗に気づきにくくなります。

sudo findmnt --verify --verbose
sudo mount /srv/data/app
findmnt /srv/data/app

GRUB の変更を反映する

/etc/default/grub を変更した場合は、構文確認後に update-grub を実行し、再起動後に /proc/cmdline を確認します。

sudo sh -n /etc/default/grub
sudo update-grub
grep -n 'console=tty0' /boot/grub/grub.cfg || true

cat /proc/cmdline

設定反映後の共通確認

反映コマンドを実行しただけで終わらせず、状態、ログ、実値を確認します。

systemctl --failed
systemctl status example.service --no-pager
journalctl -u example.service -n 50 --no-pager
systemctl is-enabled example.service

再起動が必要か判断する

すべての設定変更に再起動が必要なわけではありません。ただし、GRUB、起動時モジュール、fstab、再起動後にしか確認できない永続化設定は、再起動後確認まで行う必要があります。

• サービス設定だけなら reload または restart で足りる場合があります。
• unit 定義を変えた場合は daemon-reload と restart が必要です。
• sysctl は即時反映できますが、再起動後に維持されるか確認します。
• GRUB は update-grub と再起動後確認が必要です。
• fstab は再起動前に findmnt で確認し、再起動後にも確認します。

反映できていない時に見る項目

• 変更したファイルをサービスが本当に読んでいるか。
• reload に対応していないサービスに reload だけを実行していないか。
• systemd unit 変更後に daemon-reload を忘れていないか。
• 設定ファイルに構文エラーや権限不備がないか。
• 再起動後にしか効かない設定を即時反映だけで確認していないか。

まとめ

Ubuntu 26.04 の設定反映では、変更対象ごとに反映コマンドが違います。サービス設定は reload / restart、unit 変更は daemon-reload、sysctl は sysctl コマンド、GRUB は update-grub と再起動後確認というように切り分けると、設定が効いていない原因を追いやすくなります。

関連記事

Ubuntu 26.04 ログ確認の基本 – journalctl と /var/log を切り分ける Ubuntu 26.04 サービス状態確認の基本 – systemctl で active / enabled / failed を見る Ubuntu 26.04 再起動後確認 – 永続化された設定と起動状態を見る Ubuntu 26.04 障害時の切り分け – OS / ネットワーク / サービスを層で見る Ubuntu 26.04 journald の基本設定 – journalctl と永続ログを管理する Ubuntu 26.04 systemd の基本 – unit / target / timer とサービス管理を理解する Ubuntu 26.04 fstab によるリモートマウント – リモートストレージを固定マウントする Ubuntu 26.04 MariaDB の基本設定 – utf8mb4 とローカル接続を管理する