ディスクがどんどん減っていく（journald）
この問題は、2015年2月リリースのファームウェアでは発生しません。
journaldは、ファイルシステムの容量を把握し、残容量を監視しながら適切にログを削除してくれるはず。
デフォルトで、ファイルシステムの10%以下、残容量の15%以下。
ところが、どうも、「/var/log/journal」以下のファイル容量が増えていってしまうことがある。
当初、この原因は「reboot ota」のせいだと書いたが、どうやら違っていたようだ。 独立した原因が2個ある。
原因1
ログファイルは、「/var/log/journal」の下の、マシンIDを16進表記したディレクトリの下に作られる。
ところが、このマシンIDが、起動するたびに変化してしまう。
変化するから別のディレクトリにログを記録し、古いログの容量を把握しなくなってしまう。
この問題は、以下のように操作すれば解消される。
# umount /etc/machine-id # systemd-machine-id-setup # rm -rf /var/log/journal/* # reboot
原因2
「shutdown」できちんとシャットダウンした場合は問題無い。
ところが、「reboot」や突然の電源断を行った場合、使用中のログファイルが壊れる。
壊れたログファイルは、次回の起動時に「system@????????????????????????????????.journal~」というような名前に変更されて保存される。
このファイルは、ログファイルの定期ローテーションの際に回収され、「/etc/systemd/journald.conf」に設定したディスク容量設定に従うように適切に削除される。
ところが、短時間にこのような再起動を繰り返した場合、定期ローテーションにひっかからず、ディスク容量を食いつぶしてしまう。
これは、systemdのバグまたは制限事項であり、Edisonのバグとは言えないだろう。
消極的な対策しかない。
- 短時間に何度も再起動しないようにする。
- 短時間に何度も再起動してしまった場合は、適宜「
rm /var/log/journal/????????????????????????????????/*.journal~」というコマンドを実行する。 - Edisonで何らかの対策がなされるのを待つ。
- 「
/etc/systemd/journald.conf」に「Storage=volatile」という設定をする。
ただし、「Storage=volatile」という設定を行った場合は、カーネルパニックなどの問題をみつけて究明するのが難しくなる。
2014/11/15
