Linuxに用途を問わない単一の「restart」commandがあるわけではありません。systemd環境のserviceはsystemctl restart unit、OS全体はsystemctl rebootまたはrebootです。service一つの再起動とhost rebootは影響範囲が大きく異なるため、先にunit名と依存関係を確認します。
結論は「systemctl statusとlist-dependenciesで対象unitを確認し、設定testと利用者通知後にsystemctl restartを実行します。OS rebootはservice restartで解決できない承認済みmaintenanceに限定します」です。
service再起動とOS再起動を分ける
systemctl restartは指定unitをstopしてstartします。reloadはservice固有のconfiguration reload、reload-or-restartはreload対応ならreload、非対応ならrestart、try-restartは現在activeなunitだけrestartします。古いservice commandやdistribution固有toolはwrapperの場合があるため、init systemを確認します。
- PID 1とinit systemがsystemdか
- 正確なunit名とactive/sub state
- 設定syntax testと直近log
- dependent/requiring unitと利用者影響
- rollback用config・previous package・console access
systemctl status –no-pager unit、systemctl show、journalctl -u unitを読み、failureが設定error、port conflict、permission、dependency、resourceのどれかを確認します。restartで症状を消してlogを失う前に、直近時刻とcorrelation IDを保存します。
Linuxに万能の「restart」コマンドがあると考えず、再起動したい対象がsystemd service、SysV init script、container、daemon独自管理、OS全体のどれかを確認します。systemctl status unit、systemctl show、journalctlで現在状態、MainPID、ActiveState、直近エラーを読みます。unit名を推測せずsystemctl list-unit-filesやパッケージ資料から正式名を確定します。
unit状態と依存関係を確認する
configurationをversion管理またはbackupし、service固有のconfig testを通します。maintenance通知後にrestartを一度実行し、systemctl is-active、journal、listen port、application requestを確認します。failureなら追加restartを繰り返さず、元configへ戻して再度testします。
unit状態を読む
systemctl status --no-pager nginx.service
systemctl show nginx.service -p ActiveState -p SubState -p MainPID例のunit名は実環境のserviceへ置き換え、まず読み取りだけ行います。
依存関係を確認
systemctl list-dependencies --reverse nginx.servicerestartで影響するconsumerを把握し、表示されたunitを自動で停止しません。
serviceをrestart
sudo systemctl restart nginx.serviceconfig test、backup、承認、利用者通知を通過した後に一度だけ実行します。
reload可能ならreload
sudo systemctl reload nginx.serviceunit/serviceがreloadをsupportし設定が反映される場合だけ選びます。
結果を機械判定
systemctl is-active --quiet nginx.service
printf 'active_rc=%s\n' "$?"activeだけでapplication request成功を証明しないためhealth endpointも確認します。
systemd環境では設定変更後に必要な場合だけsystemctl daemon-reloadを行い、service自身の再起動はsystemctl restart unitを使います。設定ファイルを変更したなら、製品固有の構文検査を先に実行します。restart前に接続、queue、冗長系、依存unitを確認し、可能ならreload対応をsystemctl reload-or-restart等の公式仕様とアプリ資料で検討します。OS rebootとは別物です。
systemdのjobとactive stateを読む
systemctl commandのexit status、unitのActiveState/SubState、service main processのexit codeを分けます。restart command自体が成功してもserviceがすぐcrashする場合があります。Type=oneshot等はinactiveが正常なこともあり、unit種別と期待stateを確認します。
- systemctl restartはunitをstopしてからstartする
- reloadはserviceが対応する設定reloadでprocessを必ず再起動するわけではない
- try-restartはinactive unitを新規startしない
- daemon-reloadはunit fileのmanager設定再読込でservice設定reloadとは別である
- host rebootは全serviceとsessionへ影響しservice restartの代替ではない
systemctl restartは対象unitを停止してから起動するため、短時間でもservice interruptionが発生します。reloadはprocessを維持して設定を読み直す場合がありますが、unitがreloadを実装していなければ使えません。Restart=はserviceが異常終了した後の自動再起動方針で、管理者が手動でrestartする操作と同じ意味ではありません。依存関係により関連unitへ影響する場合があります。
停止時間を短くしてrollbackを確保する
ssh一本だけのremote hostでnetwork/ssh/firewall serviceをrestartする前にout-of-band consoleを確保します。DBやqueueはdrain、replication、transactionを確認します。sudo権限不足をpermission緩和で回避せず、service ownerへ依頼します。rollback前に現在configとpackage versionを保存します。
- unit名を推測して別serviceをrestartする
- daemon-reloadとservice reloadを混同する
- active表示だけでapplication正常とする
- failure時にrestartをloopする
- service問題にhost rebootを最初から使う
database、message queue、storage、network serviceをいきなり再起動せず、flush、drain、cluster failover、quorumなど製品固有手順を確認します。kill -9をrestart代わりに使わないでください。SSH経由でnetwork serviceを再起動する場合は接続を失う可能性があるためconsoleまたは別管理経路を準備します。sudo権限と対象hostをprompt・hostnameで再確認します。
再起動後のhealth checkを行う
restart時刻前後のjournal、MainPID、listen socket、health endpoint、error rate、queue、dependent serviceを確認します。利用者requestを一件通し、数分後もactiveでrestart loopがないことを確認します。rollback testと作業時間も記録します。
- 正しいunitと依存関係を確認した
- config test・backup・rollbackを準備した
- restart後にunit stateとapplication healthを確認した
- failure時に追加restartせず元状態へ戻せる
restart前後のActiveEnterTimestamp、MainPID、journal、listen port、health endpoint、未処理queue、利用者機能を確認します。systemctlがactiveを返してもアプリが依存先へ接続できない場合があります。再起動回数が増えていないかsystemctl showのNRestarts等を確認し、数分後にも安定しているか観察します。
reload・service restart・host rebootを選ぶ
reloadで十分ならdowntimeのあるrestartを避けます。service restartで直らずkernel、mount、hardware、updateが原因と確認できた場合だけhost rebootを別承認で計画します。systemdでない環境はdistributionのofficial init手順へ切り替えます。
設定だけを反映できるreloadが製品公式にあり、接続維持が必要ならreloadを優先します。process hang、memory leak、更新反映などrestartが必要な理由を記録し、根本原因を再起動で隠さないでください。OS全体のrebootが必要なのはkernelや基盤更新など別の要件であり、service restartの失敗から自動的に拡大しません。containerはsystemctlではなくorchestratorの健康管理とrolloutを使います。
コメント