回答:
カーネルの更新後にリブートする必要があります（KSpliceを使用している場合を除く）。その他はオプションです。個人的には、メンテナンスウィンドウ中に月に1回のサイクルで再起動して、サーバーとすべてのサービスが期待どおりに戻るようにします。このようにして、システムが正常に復帰するために予定外のリブート（つまり、重要なカーネル更新）を行う必要があるかどうかをかなり確信できます。サーバーとサービス（つまり、Nagios）の自動監視も、このプロセスを支援するのに大いに役立ちます（再起動し、ライトが赤くなり、できればすべて緑に戻ることを望みます）。
PS定期的にリブートする場合は、fsckチェックを調整する必要があります（つまり、チェック間のマウントカウントを適切に調整する必要があります。そうしないと、サーバーが数テラバイトのデータをfsckし始めると、2分間のクイックリブートに30分かかることがあります。通常、マウントカウントを0（tune2fs -c 0）に設定し、チェックの間隔を6か月程度に設定してから、時々fsckを手動で強制的に実行し、カウントをリセットします。
実行中のカーネルバージョンを絶対に変更する必要がない限り、Linuxサーバーを再起動する必要はありません。ほとんどの問題は、構成ファイルを変更し、initスクリプトを使用してサービスを再起動することで解決できます。
リブートに注意する必要があります...サービスの構成ファイルに変更を反映せずに「オンザフライ」で何かを変更した場合、それらの変更はリブート後に適用されません。
ただし、通常、スケジュールされたシステム更新後に再起動します。一般的には必要ありませんが、私はオフィスに誰もいないときにそうします。とにかく、私がアップデートを行うことになったとき、しばしばカーネルのアップグレードがあります。
実際には必要ありませんが、Linuxのメモリ処理は優れています。しかし、その長さのアップタイムがある場合は、おそらく既知の脆弱性を持つカーネルを実行しているでしょう-あなたはそれを見たいかもしれません。
最近のカーネルの更新またはlibcの更新がある場合は、再起動する必要があると思います。多くのことがlibcにリンクされているため、リブートしない限り、そのlibをメモリから完全にアンロードして新しいバージョンに置き換えることは実際には不可能です。
たとえば、/ bin / lsや/ bin内のその他の基本的なものでもlibcを使用します。コンソールを実行していてbashを使用している場合は、libcを使用しています。
$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
/lib/ld-linux.so.2 (0xb804b000)
$ ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
libc.so.6 => /lib/libc.so.6 (0xb7de7000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
/lib/ld-linux.so.2 (0xb7f61000)
libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)
はい、/ etc / init.dのファイルを変更して、何らかの形で起動に影響を与える場合は、再起動することをお勧めします。すぐに起動して実行する必要があるときに、スタートアップファイルで小さな間違いを犯したことを知りたくありません。
サーバーが再起動せずに何日も経過している場合、実際には、サーバーが再び正常に起動することを確認する方法がないことを意味します。繰り返しになりますが、これは多くの設定ファイルが変更されている可能性があり、起動することを確認するために長時間再起動した人がいないためです。また、サーバーに多数の更新プログラムがあり、長時間再起動していない場合は、更新プログラムを適用する前に再起動してください。かなり前、または適用した新しい更新。
最後に、非常に長い時間後に重要なサーバーを再起動した場合、fsckは、サーバーが回復するまで非常に長い時間待たなければならないことを意味する場合があります。tune2fsを使用してこれを回避できますが、定期的にチェックすることをお勧めします。これが、たった1台のサーバーに依存しているだけではなく、Webサイト全体がなくなってしまうような状況に陥るべきではない理由です。スタンバイに別のものが必要です。
この予想外のダウンタイムを抱えているときに探すべきもう1つのことは、メモリとプロセッサがどの程度正確に使用されているか、どのプログラムによって使用されているかを調べることです。
topどのプロセスがリソースの損失の原因であるかを判断し、それらを直接管理できる必要があります。別のアイデアは、cronjobを初期化して、特定のスケジュールでプロセスをシャットダウンおよび再起動することです。
私のインフラストラクチャには、2つのデータサイトがあります。アルファ（運用が毎日行われる）とベータ（バックアップサイト、万が一アルファで事態が悪化した場合に備えて）です。現時点ではそうではありませんが、ベータ版からすべてのサービスを実行できるように、6か月ごとにアルファサイトでダウンタイムをスケジュールするようにプッシュしています。
これにより、2つのことが達成されます。まず、災害復旧サイトが完全に実行可能であることを証明します。第二に、アルファで蓄積された残骸を取り除くのに一週間分の時間を与えてくれます。
現状では、サーバーを必要な頻度で再起動しません。必要なときにサーバーが復旧することを知っておくことが重要であると言った他のポスターに同意します。あなたは、彼らが何かを変更し、それを正しく行っていない、またはそれを文書化していないことを知るためだけに、彼らがするだろうと「考え」たくない。
マシンの現在の状態がリブート後のマシンの状態になる場合、（可能な限り）チェックするスクリプトをさらに作成できます。
これが意味するのは...
/etc/init.d/*
/etc/fstab
/etc/mtab）に対応するエントリがあることを確認します/etc/fstab/etc/fstabも現在マウントされていることを確認します。もちろん、これは決して完全なチェックではありませんが、再起動後のトラブルのリスクを減らします。
これに加えて、（imo）サーバーパッケージの更新に関するポリシーを適切な順序で設定する必要があります。たとえば、1週間に1グループ...
また、「6か月ごとにすべてのサーバーが完全なOSアップグレードを実行する」などの全体計画も立ててください。