背景
こちらの記事で購入したThinkpadを使っていた時の話です。
ある日、電源を入れると画面はつきません。
代わりに、/dev/sda2: clean, ***/*** files, ***/*** blocksを表示したまま動かないターミナルがあるだけという状態になりました。
再起動しても何も変わらない。
そんな状態から復帰させるまでのお話です。
結論はタイトル通りです。
冗長にはなりますが、あえてエラーに対処した時の話を時系列順にまとめました。
へっぽこエンジニアの物語として、あるいは未知のトラブルへの問題解決という汎用スキルの実践としてご覧ください。
GUIが立ち上がらない状況だったこともあり、画像はほとんどありません。
まずはCUIを起動して原因を探る
Alt+F2~4をすることでターミナルを起動します。
これはLinuxにある12個のターミナルにFキーがそれぞれ割り当てられるからできるらしいです。
参考記事：https://edigital.tech/archives/266
LinuxのGUI環境が立ち上がっていないのは明らかだったので、GUI環境について調べてみることにします。
gdm3というディスプレイマネージャーで動いていることがわかりました。
では、このgdm3の動作状況を調べてみよう。
ということで、systemctl status gdm3でディスプレイマネージャーが動いているかを確認します。
参考記事：https://qiita.com/ayumi-ikeda/items/1544f8004d8f18798383
動いていないとエラーで出たので、sudo systemctl start gdmで起動、sudo systemctl restart gdmで再起動、sudo dpkg-reconfigure gdm3でgdm3を再設定といろいろ試してみました。
それでも駄目なので、そもそもgdm3がうまく動いていないことがGUIが起動しない直接的な原因でないと判断しました。
他に潜む原因を探って解決していきたいと思います。
gdm3を復旧させるためにaptパッケージ周りを調べてみる
ubuntu-desktopやgdm3を再インストールしてみても、そもそもインストールできない状態でした。
パッケージ周りでなにか壊れているのではないかと判断して、一度インストールしたパッケージが問題ないか確認してみました。
ただ、自分で入れたパッケージの中には、特に変わったものは入っていない。
ではバージョン管理の問題かと、sudo権限でapt update apt autoclean apt autoremove をしてみます。
これも特に変化なく処理が終了します。
しかし、apt upgradeでのみエラーが発生しました。
ちなみにこの時、文字コードが合わないのか文字化けしてエラーログが読めない状態でした。
どうやらROMメモリに余裕がない状況なのかと考えました。
ここで推理したことは、問題なく動作したapt autocleanもapt autoremoveもキャッシュされているdebファイルや古いバージョンファイルを削除するコマンドであることです。
apt updateもパッケージ一覧を更新するのみで、apt upgradeというパッケージを更新する（新しいバージョンをインストールする）ことだけがうまくいかない現象となると、容量の問題ではないかと思い当たりました。
ということで、容量を確認していきます。
どの領域で容量を使用しているのかを確認する
ここで初めてdf -hコマンドを使用しました。
今思えばさっさと確認しておけばよかったです……。
すると、なんと/dev/sda2の使用率が100%になっていました。
これはまずい。
とりあえず消しても良いファイルを削除して、ncduを入れました。
各フォルダ・ファイルの容量を確認しながら、少しずつ削っていきます。
ただ、どうでも良い消せそうなファイルを軒並み消しても使用率は96%のままです。
ゴミ箱に入っているデータも削除してこの状態ですが、普段からアプリケーションのサイズは確認するようにしており、ファイルもほぼローカルには置かないように気をつけています。
心当たりのある使用量ではありません。
sudo du -s -h /* | sort -nrで確認するとどうやら/var/ディレクトリに220GBほど容量を使っているようでした。（SSD256GB積みなので明らかにここが原因）
ここで早合点して、なるほどキャッシュファイルが原因かとrm /var/cache/apt/archives/*でキャッシュを消してみるも変化なし。
もう少し辿ってみると、/var/log/の中にsyslog.1という200GB超えのファイルを発見しました。
こいつがすべての元凶です。
syslog.2以降は圧縮されているのか容量は大したことないのですが、syslog.1のシステムログが肥大化していたのが原因でした。
一定のファイルサイズに達したり、一定の期間が経過したらファイルを切り分け、古くなったファイルは圧縮・消去するようになっているはずがうまくいっていないようです。
ここ最近色んなパッケージを追加しており、単純にコーディング量も多かったところから、一定の期間というところが怪しいと思いました。
ここで対処すべきはまず容量いっぱいで身動きが取れない状況を改善することです。
それが済んだ後にログファイルの設定を確認する必要があります。
参考記事：https://atmarkit.itmedia.co.jp/ait/articles/0209/07/news002.html
syslogを削除し、logrotateの設定を変更する
まずはsyslog.1ファイルを削除することにします。
ただ、普通にsudo rmでも削除できません。
どうやらシステムログまわりにもガーベジコレクションがあるらしく、巨大すぎるデータは削除できないことがあるようです。
mvコマンドでファイル名を変更した後、rmコマンドで削除することができました。
参考記事：https://blog.hde.co.jp/entry/2014/11/28/171114
ここでdf -hで容量を確認すると、ちゃんと容量が確保されていました。
再起動したところGUIが立ち上がったので、対処に成功したようです！
ここからは同じ目に遭わないように、対策を打つフェーズです。
ログローテーションの設定ファイルであるlogrotate.confを確認しました。
すると、1週間ごとに4回分のログを保存しているようでした。
また、圧縮する設定がコメントアウトされており、無効になっていました。
logrotate.confと/etc/logrotate.d/rsyslogの設定を変更しておきます。
毎週ログを取り、4回分（約1ヶ月）保存している設定を1日ごとに7回（1週間）にしてみました。
また、COMPRESSのコメントアウトを解除して圧縮するように設定を変更しました。
sudo systemctl restart rsyslogで反映して、対策完了です。
とりあえずこれでしばらく様子を見てみます。
おわりに
多くのエンジニアにとっては特別学びもない退屈な記事だったかもしれません。
厳密さよりもその時その瞬間考えたことをそのまま文章にしているため（後から補足しているところもあるとはいえ）解説としても決して親切ではないです。
ただ、こういった突然の見に覚えのないエラーに対処するという経験は、自分の中にエンジニアらしさを見い出せて充足感を覚えました。
まだまだ精進していく身ではありますが、知らないバグやエラーに不安を抱きながら立ち向かう若手エンジニアの皆さんに少しでも勇気と泥臭くやることの重要性を伝えられたら幸いです。
一連の流れの後で衝動的に書いた記事であったため、後に間違った情報を書いていないかチェックはしてあるものの不備があるかもしれません。
誤った知識を流布するのは私の意図しないことですので、ご指摘をいただけると幸いです。