問題発生
某サービスがバンドルされたAMIから立てた開発EC2に、Webアクセス出来なくなったと連絡があり
ちろっと調べて見たところ、logに
java.io.IOException: No space left on device
がずらっと並んでいた。
No space...
root@ip~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.6G 7.6G 0 100% / #←あぁ〜
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.8G 0 3.8G 0% /dev/shm
tmpfs 774M 800K 774M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
ぱんぱんになっていた。
EBSデフォルトだったしファイル特に生成しないから8Gでいいやって思ってたらそうでもなかったらしい。
復旧作業
-
AWSの管理コンソールでEBSの容量を増やした(8GB➝64GB)
-
適用され次第EC2に入って拡張状況を確認
-
lsblkで拡張対象のボリュームを確認（今回は
nvme0n1） -
p1に対して拡張コマンドドーン！楽ちん！
growpart /dev/nvme0n1 1
mkdir: cannot create directory '/tmp/growpart.XXXX': No space left on device
FAILED: failed to make temp dir
5. 拡張ができない
何が起きたか
こちらの方の記事からヒントを得ました。
要はgrowpartによるtmpファイルすら作れないっすよってことですね、そりゃそうだな100%だし。
どうしたか
ファイルを消すと言っても元々AMIだから何かファイルを設置した訳でもないし
サービスはjavaだし何消していいか分かんないし
アプリのlogディレクトリはKB単位のファイルばっかりで意味ないし
何か調べたらEBSをデタッチして新しいやつ付けるみたいな絶対やりたくない情報ばっかりだし
〜〜〜〜
（消しても大丈夫そうなファイル探しの旅30分）
〜〜〜〜
ということで辿り着いたのがjournalディレクトリ。
790MBもある！たまらんなこの状態。
root@mentaiko.jp:/var/log/journal# ls -lah
total 790M
drwxr-sr-x+ 2 root systemd-journal 4.0K Feb 1 07:10 .
drwxr-sr-x+ 3 root systemd-journal 4.0K Nov 7 14:56 ..
-rw-r-----+ 1 root systemd-journal 0 Feb 1 08:02 system.journal
-rw-r-----+ 1 root systemd-journal 4.0K Feb 1 07:10 system@0005f39e25acd5e9-5a2015722c9a6000.journal~
-rw-r-----+ 1 root systemd-journal 8.0M Feb 1 01:27 system@1411a339f5314c08af496cf3496dbb3a-0000000000000001-0005f395e59e19fd.journal
-rw-r-----+ 1 root systemd-journal 8.0M Feb 1 01:27 system@1411a339f5314c08af496cf3496dbb3a-0000000000002231-0005f39704ef83a5.journal
-rw-r-----+ 1 root systemd-journal 8.0M Feb 1 03:23 system@1411a339f5314c08af496cf3496dbb3a-0000000000004494-0005f39842c56730.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 16:02 system@2c66650ab65f427cbd99462e39729dcf-0000000000000001-0005f38d77b6aaed.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 16:02 system@2c66650ab65f427cbd99462e39729dcf-000000000000225d-0005f38eb80a6360.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 16:02 system@2c66650ab65f427cbd99462e39729dcf-0000000000004655-0005f38edd7c590b.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 16:02 system@2c66650ab65f427cbd99462e39729dcf-0000000000006aa8-0005f38ee57998d6.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 16:02 system@2c66650ab65f427cbd99462e39729dcf-0000000000008d81-0005f38ff2ef7a8b.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 21:20 system@2c66650ab65f427cbd99462e39729dcf-000000000000afff-0005f39114ab026d.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 2 09:02 system@9df0656564b94f7eaa62358b21a29ba3-0000000000494a95-0005f1442fce7257.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 2 09:32 system@9df0656564b94f7eaa62358b21a29ba3-00000000004b2f27-0005f1449ad789d4.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 11:16 system@9df0656564b94f7eaa62358b21a29ba3-000000000051da2f-0005f14754357f4d.journal
-rw-r-----+ 1 root systemd-journal 0 Feb 1 03:23 user-1001@0005f39af91bb78a-c1b3e62d7e5f26e3.journal~
-rw-r-----+ 1 root systemd-journal 97M Jan 2 08:30 user-1001@16538e11502a4199a9f383d579700084-0000000000455aaa-0005f143516d8ad9.journal
-rw-r-----+ 1 root systemd-journal 97M Jan 2 09:02 user-1001@16538e11502a4199a9f383d579700084-000000000047647a-0005f143c47ce664.journal
-rw-r-----+ 1 root systemd-journal 97M Jan 2 09:35 user-1001@16538e11502a4199a9f383d579700084-0000000000496e5b-0005f14437b70c3c.journal
-rw-r-----+ 1 root systemd-journal 97M Jan 2 10:07 user-1001@16538e11502a4199a9f383d579700084-00000000004b783d-0005f144aafe8510.journal
-rw-r-----+ 1 root systemd-journal 97M Jan 2 10:39 user-1001@16538e11502a4199a9f383d579700084-00000000004d8215-0005f1451e4b883b.journal
-rw-r-----+ 1 root systemd-journal 97M Jan 2 11:12 user-1001@16538e11502a4199a9f383d579700084-00000000004f8bd0-0005f14591bd90ad.journal
-rw-r-----+ 1 root systemd-journal 96M Jan 31 11:16 user-1001@16538e11502a4199a9f383d579700084-000000000051958a-0005f146053616eb.journal
-rw-r-----+ 1 root systemd-journal 8.0M Feb 1 03:23 user-1001@42d541f3117f4e2987bf8d350e1d25f7-000000000054ceb6-0005f399593c8769.journal
-rw-r-----+ 1 root systemd-journal 8.0M Jan 31 21:20 user-1001@4913bb3919ac468da43b330a7ec45941-000000000054474d-0005f39173b950c1.journal
1月2日のやつ絶対いらんよな。
これrmで消していいのかしら、念のため調べてみる。
先人の知恵 is Godだな〜。
残してても分かるもんでもないので3日前までのを残すバキュームオプションを付けて実行。
journalctl --vacuum-time=3d
改めてdf
root@ip〜# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.6G 7.0G 662M 92% /
devtmpfs 3.8G 0 3.8G 0% /dev
略
8%空いた！！
root@ip~# growpart /dev/nvme0n1 1
CHANGED: partition=1 start=227328 old: size=16549855 end=16777183 new: size=133990367 end=134217695
通った！！
root@ip~# resize2fs /dev/nvme0n1p1
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/nvme0n1p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 8
The filesystem on /dev/nvme0n1p1 is now 16748795 (4k) blocks long.
載った！！
root@ip~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 62G 7.0G 55G 12% /
略
解決した！！（ここで満足したがついでにシステムも動いた）
おわり。