2000年代半ば（ちょうど10年）にコンピューターを使用するのに十分な年齢で、たまたまWindowsとLinuxを実行していて、オタクである場合は、このオペレーティングシステムの利点に関するディスカッションにも参加しました。 、次に、次のステートメントに出くわしたはずです。Linuxでシステムのメンテナンスを行う必要はなく、すべてを単独で処理するのに十分スマートです。
実際、Windows側では、システムが時間の経過とともに遅くなる、デフラグの緊急の必要性（Ext3ではなくNTFS）、一時ファイルのクリーンアップなどについてよく話し合われました。 Linuxはしばしばメンテナンスフリーとして宣伝されていました。さて、問題は、このステートメントが実際にどれほど真実であるかということです。私は実際に、一時的なチャンスを通して、自分でそれをテストする機会がありました。
どうしたの？
SlimbookのKubuntu18.04インスタンスでパッケージのインストールと削除を行っていましたが、突然、操作が失敗しました。 Apt、（コマンドライン）パッケージマネージャーは、デバイス[原文のまま]にスペースが残っていないため、操作を完了できなかったと私に言いました。なに。
gzip：stdout：デバイスにスペースが残っていません
E：mkinitramfs failure find 141 cpio 141 gzip 1
update-initramfs：failed for /boot/initrd.img-4.15.0-163-genericwith1。
dpkg：パッケージinitramfs-tools（--configure）の処理中にエラーが発生しました：
インストールされたinitramfs-toolsパッケージのインストール後のスクリプトサブプロセスがエラー終了ステータス1を返しました
処理中にエラーが発生しました：
linux-image-4.15.0-166-generic
initramfs-tools
ここで興味深いのは、私は正常に作業していて、中断はなかったということです。ディスクにはスペースがありましたが、比較的小さいものでしたが（思ったよりも小さいですが、500GB SSDにはまだ約20GB残っています）、さらに重要なことに、システムから問題が発生したというメッセージや警告はありませんでした。
しかし、それから、私は/ bootパーティションの内容を調べました、そして見よ：
df -lh / boot
使用されるファイルシステムのサイズ使用率使用率
/ dev / sda2 705M 705M 0M 100％/ boot
何。奇妙な理由で、私の重要ではない/ bootパーティションがいっぱいになりました。これは、これ以降のカーネルまたはinitramfs操作が失敗することを意味します。これは良いことではありません。特に、カーネルの更新があった場合はどうなるでしょうか。
次に、aptに対して「autoremove」コマンドを実行することにしました。これにより、未使用のパッケージがクリーンアップされます。数分間の厳密なパージの後、状況は通常に戻りました：
df -lh / boot
使用されるファイルシステムのサイズ使用率使用率
/ dev / sda2 705M 155M 500M 24％/ boot
ここでのレッスン
フルディスク暗号化のセットアップが整っていて、3年前にインストーラーによって実装されたときに制御できなかったことが判明しました。さまざまなパーティションのサイズなどが自動的に設定されたため、/bootが不足することになりました。カーネルアップデートの典型的なUbuntuファミリーのリズムで、約3。5年の使用後のスペース。
もちろん、これで解決策は明らかです。未使用のパッケージをときどきパージします。公平を期すために、aptは、メンテナンスコマンドを実行するときに常にこれを通知します。これは、削除できるものがたくさんあることを示しています。これにより、ディスクの使用量が削減されます。コマンドラインで。
だが。だが。 DiscoverなどのGUIパッケージマネージャーを実行している場合、このようなメッセージは表示されません。これは、Linuxを従来のデスクトップ方式で使用している一般の人々、つまりコマンドラインウィザードがない場合、Linuxマシンを十分に長く使用し続けると、最終的にはLinuxマシンでそれほどメンテナンスフリーではない問題が発生することを意味します。
クリーンアップの一環として、ncduも実行し、/ varの下にたくさんの残り物、コンテナ、仮想マシンが長い間使用されておらず、それぞれのサービスでクリーンアップされていないことなど、ディスク上にあらゆる種類のがらくたを見つけました。繰り返しになりますが、次のような予見によって改善できるものがあります。a）コアシステムディレクトリをユーザーファイルからより適切に分離する（仮想マシンを/ varの下に保持しない）b）より適切な自動クリーンアップc）実際の警告とエンドユーザーへの通知。
私はずっと前に、Linuxでのサービス間の認識が限られているというこの全体的な問題を強調しました。本当のまとまりはありません。システムがブートループでスタックしている場合、手動で介入しない限り、このループを中断するものはありません。システムの速度を低下させるサービス、バグのあるコード、システムとうまく統合されていないものがある場合、それを伝えるものは何もありません。すべてが独自の空間に存在し、さらに悪いことに、自己チェックや自己回復のメカニズムはありません。
結論
これは私の小さな逸話です。初めて、私は問題に遭遇しました。以前は、システムに単一のルートパーティションを使用していましたが、ディスク暗号化は使用していませんでした。つまり、/ bootはシステム自体と同じように拡張可能であり、更新後のスペースが問題になることはありませんでした。しかし、ここで、私は、システムを非オタクな方法で（GUIを介して）使用し、手動の保守作業を行わない人々を噛む可能性があり、噛む可能性がある何かに遭遇しました。
真の解決策は、Linuxシステムをより回復力のあるものにし、サービスまたはプログラムごとに、そしてシステム全体にわたって、はるかに優れたエラー管理を行うことです。何がうまくいかなかったのか、さまざまなコンポーネントがどのように相互作用するのかを理解するツールがないため、検出されない、または報告されないことが多い他の多くの問題やバグを解決するのにも役立ちます。さて、あなたは行きます。あなたはこれが面白いと思うでしょう。またね。