Linuxサーバーは定期的に再起動した方がいい?再起動しない運用は問題?

Linux

Linuxサーバーを長期間運用していると、「定期的に再起動した方がいいのか?」「何か月も再起動していないけど大丈夫?」と気になることがあります。

結論からいうと、Linuxサーバーも「毎週」「毎月」など一律の周期を決めて再起動するのではなく、更新内容やサーバーの状態を確認して、必要なときに計画的に再起動すると考えるのがよいでしょう。

特にカーネルを更新した場合は、新しいカーネルを有効にするため再起動が必要になります。

Linuxサーバーを定期的に再起動する必要性と判断方法
カーネル更新や再起動要求を確認してLinuxサーバーの再起動タイミングを判断

Linuxサーバーは定期的に再起動した方がいい?

Linuxは長期間連続稼働できるOSです。

正常に動作していて、再起動を必要とする更新もなく、CPU・メモリ・ディスク・サービスなどにも問題がなければ、単純に「1か月経ったから」という理由だけで再起動する必要性は高くありません。

重要なのは稼働日数ではなく、

  • カーネルを更新したか
  • 重要なライブラリを更新したか
  • 再起動が必要な状態になっているか
  • サービスに問題が発生していないか
  • リソースに異常がないか

といった点です。

カーネルを更新したら再起動が必要

Linuxで特に注意したいのがカーネル更新です。

例えばRHEL系Linuxで新しいカーネルパッケージをインストールしても、その瞬間に実行中のカーネルが新しいものへ切り替わるわけではありません。

通常はサーバーを再起動し、新しいカーネルで起動する必要があります。

Red Hatのドキュメントでも、カーネル更新後に変更を有効にするためシステムを再起動する手順が案内されています。

現在動いているカーネルを確認する

現在使用しているカーネルは次のコマンドで確認できます。

uname -r

インストールされているカーネルと比較すれば、新しいカーネルをインストールしたまま再起動していないことに気付ける場合があります。

RHEL・Rocky Linux・AlmaLinux系なら、例えば次のように確認できます。

rpm -q kernel
uname -r

新しいカーネルがインストール済みなのに uname -r が古いバージョンなら、まだ古いカーネルで動作している可能性があります。

RHEL系ではneeds-restartingで確認できる

RHEL系Linuxでは、更新後に再起動が必要かを判断するための needs-restarting が利用できます。

例えば、更新後に次のように実行します。

dnf needs-restarting

更新前のファイルを使用し続けているプロセスを確認できます。

環境によっては、システム全体の再起動が推奨されるかを確認するため、次のオプションも利用できます。

dnf needs-restarting -r

またはバージョンによって、

dnf needs-restarting --reboothint

が利用されます。

「毎月だから再起動する」より、こうした情報を確認して判断する方が合理的です。

Ubuntuではreboot-requiredを確認

Ubuntuでは、更新によって再起動が必要になった場合、次のファイルが作成されることがあります。

/var/run/reboot-required

例えば次のように確認できます。

if [ -f /var/run/reboot-required ]; then
    echo "再起動が必要です"
else
    echo "現時点ではreboot-requiredはありません"
fi

Ubuntuの自動更新機能でも、このファイルを検出して再起動が必要かを判断する仕組みが使われています。

Livepatchを使えば再起動しなくていい?

UbuntuにはCanonical Livepatchがあり、稼働中のカーネルへ一部のセキュリティ修正を適用できます。

これによって、重大なカーネル脆弱性への対応で再起動回数を減らせる場合があります。

ただし、Livepatchを使えば永久に再起動不要になるわけではありません。

Canonicalによると、新しいカーネルバージョンへの切り替えのほか、CPUファームウェア・マイクロコード、glibcなどの低レベルコンポーネントの更新では再起動が必要になる場合があります。

Livepatchは「再起動を完全になくす仕組み」ではなく、必要な再起動を計画できるまで重要な脆弱性への対策を行う仕組みと考えると分かりやすいでしょう。

サービスの再起動だけで済む場合もある

Linuxのパッケージを更新したからといって、必ずOS全体を再起動するとは限りません。

例えばWebサーバーなど特定のサービスだけを更新した場合、そのサービスを再起動することで新しいプログラムを読み込める場合があります。

例えばApacheなら、環境に応じて次のような操作になります。

systemctl restart httpd

UbuntuなどでApacheのサービス名が apache2 の場合は、

systemctl restart apache2

となります。

ただしサービスを再起動すると、そのサービスを利用しているユーザーやアプリケーションに影響する可能性があります。

共有ライブラリ更新にも注意

Linuxでは、glibcやOpenSSLなどの共有ライブラリを更新しても、すでに動作しているプロセスが古いライブラリを使用し続ける場合があります。

Red Hatも、更新された共有ライブラリについて、実行中のプロセスは再起動されるまで以前にマッピングされたライブラリを使い続けることを説明しています。

そのため、パッケージ更新が完了したことと、実行中のすべてのプロセスが更新後のコードを使用していることは同じではありません。

「調子が悪いから定期再起動」は注意

例えば、

  • メモリ使用量が増え続ける
  • 特定サービスが数日で応答しなくなる
  • プロセス数が増え続ける
  • ディスク使用量が異常に増える

といった問題があり、「毎週日曜日に再起動すれば直る」という運用になっている場合は注意が必要です。

再起動によって一時的に改善しても、根本原因が解決したわけではありません。

まず、

top
free -h
df -h
ps aux
systemctl --failed
journalctl -p err

などを利用して状態を確認します。

再起動する前にログやリソース状況を記録しておくと、原因調査にも役立ちます。

uptimeが長いほど優秀というわけでもない

Linuxでは次のコマンドで稼働時間を確認できます。

uptime

何百日も稼働しているサーバーを見ると「安定している」と感じることがあります。

しかし、uptimeが長いこと自体がサーバーの安全性を示すわけではありません。

新しいカーネルがインストールされているのに何か月も再起動しておらず、古いカーネルで動き続けているのであれば、長いuptimeを維持することより更新を反映する方が重要です。

再起動前に確認したいこと

本番Linuxサーバーを再起動する場合は、事前に次のような項目を確認します。

  • 利用者への影響
  • バックアップの状態
  • 更新したパッケージ
  • カーネル更新の有無
  • 自動起動するサービス
  • 依存する他サーバー
  • 再起動後の確認項目
  • 問題発生時の復旧方法

再起動後はサービスを確認する

再起動コマンドを実行してログインできたからといって、作業完了とは限りません。

再起動後は主要なサービスが正常に動作していることを確認します。

例えば、

systemctl --failed

で起動に失敗したsystemdユニットを確認できます。

さらに、Webサーバー、データベース、メールサーバーなど、そのサーバーが提供しているサービスについて実際の動作確認を行います。

Windows Serverも同じ考え方

この考え方はWindows Serverでも似ています。

Windows Serverについても、「毎月だから再起動する」のではなく、Windows Updateの再起動要求、障害、構成変更などから必要性を判断する方法を以下の記事で解説しています。

▶ Windows Serverは定期的に再起動した方がいい?再起動しない運用は問題?

Linuxサーバーのおすすめ運用

Linuxサーバーでは、次のような流れで管理すると分かりやすいでしょう。

  1. セキュリティ更新やパッケージ更新を適用する
  2. カーネルなど更新内容を確認する
  3. 再起動が必要か確認する
  4. 必要ならメンテナンス時間を確保する
  5. サーバーを再起動する
  6. 新しいカーネルで起動したことを確認する
  7. 主要サービスとログを確認する

まとめ

Linuxサーバーも、毎週・毎月と機械的に再起動する必要はありません。

一方、カーネル更新など、再起動しなければ更新内容が完全に反映されないケースがあります。

RHEL系なら dnf needs-restarting、Ubuntuなら /var/run/reboot-required なども判断材料になります。

また、特定サービスやアプリケーションの問題を定期再起動だけで回避している場合は、ログやリソース状況を確認して根本原因を調査することも重要です。

「何日稼働したか」ではなく、「何を更新したか」「再起動が必要か」「業務へどのような影響があるか」で判断して、計画的に再起動するのがおすすめです。

参考情報

コメント

タイトルとURLをコピーしました