問題発生

某サービスがバンドルされた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% /
略

解決した！！（ここで満足したがついでにシステムも動いた）

おわり。