Linux PCを起動できる最大時間は？[閉まっている]

実際、リブートせずに数日間Linuxシステム（Ubuntu 12.04.3を実行）を使用していました。スリープ状態になるなどのエラーが発生したり、一部のネットワークマウントされたファイルシステムがpingを実行することさえできません（他のPCで確認したところ、ネットワークマウントは正常に機能していました）。

繰り返し不可能なこの種の厄介なエラーを回避するために、Linuxがある時間枠後にマシンを再起動する必要があるかどうかを確認したいと考えていました。

PCを維持できる最大時間は？再起動せずに1年以上システムを稼働している場合に発生する可能性のある他の問題はありますか？

システム管理者として働いていると、Linuxサーバーが再起動せずに700〜800日間以上表示されるため、稼働時間の制限はありません。取得したエラーは、Linux（カーネル）自体とは関係ありません。

多くのサービスを再起動でき、ほとんどのエラーは本番システムで解決できます。

一定の時間後にコンピューターを再起動する技術的な必要はありません。私は数か月間（カーネルモジュールの更新を含む）実行しており、その間に（RAMとディスクへの）一時停止がありました。

機会があります

• カーネルの更新のように、リブートが絶対に必要です（ただし、多くの場合、これらは緊急ではありません。また、稼働中のカーネルを稼働中のシステムの新しいカーネルに置き換えることができます。kexecおよびKspliceを参照してください）
• 特定の（セットの）サブシステムではなく、システム全体を再起動する方が簡単な場合があります。

時間が経つにつれて「悪化」する問題（ハードウェアドライバーの問題、漏れやすいプロセスなど）が存在する場合がありますが、それらはバグと見なされ、ソフトウェアのアップグレードで修正されるか、特定のサブシステムのリロード/再起動によって回避できます上記を参照）。

稼働時間が長いサーバーがあることは確かですが、可能な例として、私のサーバーの1つから以下を紹介します。

# uptime
04:58:44 up 2186 days, 23:15,  1 user,  load average: 0.02, 0.02, 0.00

このサーバーは、DCが稼働した直後にインストールされ、それ以降オフにされていません。これまでのところ、元々意図していたことを喜んで実行し続けており、その目的が別のサーバーに移動すると、稼働時間を監視するためにそこに何かを置きます。もう。

したがって、「最大値はありません」は間違いなく正しい答えだと思います。

これがシステムの安定性に影響を与えるかどうかはわかりませんが、カーネル3.19-xxを使用したUbuntuで示される最大稼働時間は68,0962597349822、32ビットマシン292471208677,8627では64年、64 ビットマシンでは何年もかかります。

これは、sysinfo()syscall によって返されるシステムの現在のアップタイムが__kernel_long_ttype として返されるためです。これは、32ビットカーネルではa として、64ビットカーネルではa としてlong宣言されます。long long

long32ビットマシンのAの最大値は2147483647;です。

long long64ビットマシンのAの最大値は9223372036854775807;です。

計算を行う2147483647s= 68,0962597349822年と9223372036854775807s= 292471208677,8627年。

この値がその型の能力を超えて増加すると、算術オーバーフローが発生し、その型で許容される最小値（両方の場合で負の数）に設定されます。これは、それに依存するプログラムの問題になる可能性があります。

私は、10年以上リブートなしで実行されているLinuxサーバーを持っていると主張するシステム管理者とかつてクラスにいました。システムを定期的に再起動する必要があるという固有の理由はありません。カーネルの更新などの限られたインスタンスでのみ必要です。

FWIW、私は通常、Windowsホームコンピューターを実行したままにします。通常、再起動せずに数週間は正常に動作します。

Linux（カーネル）は、プログラムの終了時にリソースを解放するのに非常に優れています。OS全体であるGNU / Linuxは、一般に無期限に実行しても問題ありません。更新後にユーザースペースプログラムを再起動することは一般に良い考えであり、多くの場合、更新を使用してすべてを取得する最も簡単な方法glibcはシステムを再起動することです。

ドライバーのバグがあるシステム（通常はグラフィックスドライバーのバグ、他のすべては通常堅実）では、すぐに再起動しないと奇妙な動作をすることがあります。dmesg出力にカーネルOOPSが表示された場合は、できるだけ早く再起動して報告する必要があります（または、既知の問題の場合は、同様のハードウェアで同様の問題を抱えている他のユーザーをグーグルで調べます）。ディストリビューションはグラフィックスタックの最新の開発バージョンを出荷していないため、バグがアップストリームで既に修正されている場合があります。また、実行中のディストリビューションバージョンのドライバーにとってグラフィックカードがあまりにも新しいため、安定していません。その場合は、mesa / drm / xorgの更新されたビルドでPPAを探してください。（最先端のグラフィックススタックでUbuntuを実行するための最良の選択がATMであるかどうかはわかりません）。

とにかく、ドライバーや他のカーネルのバグを除いて、Linuxはメモリーの断片化などをクリアするために再起動を必要とせずに無期限に実行できます。

Linuxルーター/ファイアウォール/メールサーバー/シェルボックス（P3 450MHz、OCed to 500MHz）があり、定期的に何百日ものアップタイムが発生しています。電源コードを再配置するか、障害のある電源を交換するためにのみ再起動します。おそらく15年間、同じCPU / RAM /ハードドライブで安定しています。「不安定になったため」再起動する必要はありませんでした。これは、電源の故障、カーネルのアップグレード、停電などの特定の理由で常に発生し、UPSバッテリーがほとんど消耗していました（自動シャットダウンのトリガーapcupsd）。

システムが異常な動作をしている場合はdmesg、問題がないか確認してください。デスクトップだけの場合、カーネルパッケージ以外のアップデートをインストールしたばかりの場合は、ログアウト/ログインします（または再起動しますが、再起動する必要はありません）。Kubintu 15.04はパッケージの更新後に簡単に問題が発生することがわかりました。同じバイナリで実行されている同じライブラリのアップグレードされたバージョンとアップグレードされていないバージョンのバイナリ互換性がないためです。（このバグに関する議論を参照）。

ハードウェアの問題をチェックするには、memtest86 +を起動します。（aptitude install memtest86+）フルパスを実行するか、一晩実行します。最近のCPUではスパイク負荷で電源電圧が低下する可能性があるため、安定したシステムを保証するものではなく、memtestはそれを排除しません。Prime95のようにCPUが熱くなることもありません。

私が思い出すことができる奇妙なエラーなしで11日間稼働した後、私のマシンは15.04で今日再起動しました。システムで多大な作業と開発を行っている場合、それがリブートする唯一のオプションになることもありますが、必要な場合に限ります。

技術的には制限はありません。スリープまたはシャットダウンしないように設定する必要があります。

個人的には、再起動したりシャットダウンしたりせずにラップトップやPCを何日も実行したくないでしょう。

単に熱を発生する主要なコンポーネントが原因で、MBの摩耗を加速できます。

（適切な冷却と換気がない場合）

Ubuntuに固有ではありませんが、単一のプログラム（およびシステムスタッフとconky）を実行している間に60日以上の稼働時間があったDebianベースのディストリビューションを実行する1997年のビンテージラップトップ（300 MHz、288 MB RAM）があります。更新を毎週ロードするためのターミナル以外の他のソフトウェアを起動および停止しない。最終的に、更新プログラムを読み込むときに約63日でクラッシュしました。対照的に、Kubuntu 14.04デスクトップシステムは、約2週間後に画面ロックでフリーズします。私は他の答えに同意します。Linux自体よりも、実行するソフトウェアと他のプログラムの起動と停止の頻度に関するものです。