Ubuntu 18.04 でエラー発生
ある日、突然 Let’s Encrypt から証明書の期限が切れるメールが届きました。
その証明書は、開発サーバ( Ubuntu 18.04 )で利用していたドメインでした。 cron で自動更新できるようにしていたのに、なぜか更新できていない状態になっていたようでした。
実際にサーバに SSH で接続し、手動で証明書の更新を試みます。
しかし、「No space left on device」とエラーが表示され、実行できないようでした。そのほか、何か処理を行おうとしても同様なエラーが発生します。
ディスク使用量の確認
そのためディスク使用量の確認をしてみます。
*****:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 977M 0 977M 0% /dev
tmpfs 199M 21M 178M 11% /run
/dev/xvda1 7.7G 7.7G 0 100% /
tmpfs 991M 0 991M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 991M 0 991M 0% /sys/fs/cgroup
：
tmpfs 199M 0 199M 0% /run/user/1000
ルートが100%ですね。しばらく放置していました。。。ディスクの整理をしたいと思います。
*****:~$ sudo du -sh /*
15M /bin
159M /boot
0 /dev
9.3M /etc
178M /home
0 /initrd.img
0 /initrd.img.old
408M /lib
4.0K /lib64
16K /lost+found
4.0K /media
4.0K /mnt
4.0K /opt
0 /proc
60K /root
21M /run
15M /sbin
1.3G /snap
4.0K /srv
0 /sys
48K /tmp
4.8G /usr
2.2G /var
0 /vmlinuz
0 /vmlinuz.old
「/usr」や「/var」が使用量が高いですね。何かしようとするとエラーが発生するので、手っ取り早くログファイルの削除から行います。
Journal ログの削除
もう少し具体的に掘り下げて確認します。
*****:~$ sudo du -sh /var/*
576K /var/backups
131M /var/cache
4.0K /var/crash
1.1G /var/lib
4.0K /var/local
0 /var/lock
812M /var/log
4.0K /var/mail
4.0K /var/opt
0 /var/run
52K /var/snap
36K /var/spool
32K /var/tmp
206M /var/www
「/var/log」は比較的削除しやすいので、さらにこちらを掘り下げましょう。
*****:~$ sudo du -sh /var/log/*
0 /var/log/alternatives.log
4.0K /var/log/alternatives.log.1
：
120K /var/log/amazon
212K /var/log/apache2
128K /var/log/apt
1.3M /var/log/auth.log
2.4M /var/log/auth.log.1
：
340K /var/log/btmp
2.4M /var/log/btmp.1
28K /var/log/cloud-init-output.log
840K /var/log/cloud-init.log
4.0K /var/log/dist-upgrade
0 /var/log/dpkg.log
8.0K /var/log/dpkg.log.1
：
802M /var/log/journal
0 /var/log/kern.log
4.0K /var/log/kern.log.1
：
4.0K /var/log/landscape
4.0K /var/log/lastlog
252K /var/log/letsencrypt
68K /var/log/letsencrypt-renew.log
4.0K /var/log/lxd
52K /var/log/syslog
328K /var/log/syslog.1
：
4.0K /var/log/tallylog
64K /var/log/unattended-upgrades
0 /var/log/wtmp
4.0K /var/log/wtmp.1
「/var/log/journal」が大きいですね。これは「journalctl」でログを整理します。念のため使用量を確認します。
*****:~$ journalctl --disk-usage
Archived and active journals take up 801.8M in the file system.
3日分ほど残してあとは削除します。
*****:~$ sudo journalctl --vacuum-time=3d
Vacuuming done, freed 0B of archived journals from /run/log/journal/901443452bfb4bef949b03319d972dc3.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Deleted empty archived journal /var/log/journal/901443452bfb4bef949b03319d972dc3/system@0005e81cf21a7900-2a0f744923fd9632.journal~ (704.0K).
Deleted empty archived journal /var/log/journal/901443452bfb4bef949b03319d972dc3/system@0005e8452dc39da4-c42f2a2d4a1d0662.journal~ (4.0K).
：
再度使用量を確認します。
*****:~$ journalctl --disk-usage
Archived and active journals take up 32.0M in the file system.
サイズが小さくなりました。これでディスクに余裕ができたので、いろいろなコマンドを入力してもエラーが出なくなりました。
apt の整理
あと「/usr」もサイズが大きいので、更に掘り下げます。
*****:~$ sudo du -sh /usr/*
113M /usr/bin
4.0K /usr/games
28M /usr/include
526M /usr/lib
56K /usr/local
13M /usr/sbin
222M /usr/share
3.9G /usr/src
「/usr/src」が圧迫していますね。このフォルダには「linux-aws-5.*-headers-5.*.0-****」などの古いカーネルが溜まります。そのためキレイにしてあげる必要があります。手っ取り早く apt にお任せします。
*****:~$ sudo apt autoremove
整理完了
再度ディスクの使用量を確認してみます。
*****:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 977M 0 977M 0% /dev
tmpfs 199M 768K 198M 1% /run
/dev/xvda1 7.7G 3.4G 4.4G 44% /
tmpfs 991M 0 991M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 991M 0 991M 0% /sys/fs/cgroup
：
tmpfs 199M 0 199M 0% /run/user/1000
ルートは 44% まで減りました。これでまたしばらくは大丈夫でしょう。
まとめ
今回ディスクを整理するきっかけとなった最初のメールは、比較的時間に余裕のある時に届いたものでした。コマンドがエラーになっても焦らずに対処できましたが、忙しいときだと思うと怖いですね。
開発サーバなので放置気味だったのですが、ディスク容量を監視しておいたほうがいいと思いました。