Investigate a filesystem capacity incident.

Instruction: In Stage 1, select two read-only checks. Then reveal Stage 2 and give a safe recovery sequence.

Context:

Stage 1. A fictional Linux service raises a low-space alert on its log filesystem. An operator removed an old 12 GiB log, but the filesystem reports approximately the same usage. Explain two plausible causes and the observations that would separate them before opening Stage 2.

$ df -h /srv/app
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb1        100G   98G  1.0G  99% /srv/app
$ du -xsh /srv/app
86G     /srv/app
Stage 2 — inspect after naming your first checks

These authorized observations are from the same host and filesystem; the process has not restarted. The application runbook documents a log-reopen operation that closes the old log and opens its configured path.

$ df -i /srv/app
Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/vdb1      6553600 65536 6488064    1% /srv/app
$ lsof -a -p 2174 +L1
COMMAND  PID USER FD TYPE DEVICE    SIZE/OFF NLINK NODE NAME
api     2174 app   7w REG  252,17 12884901888     0 9102 /srv/app/api.log.1 (deleted)

Updated

Official answer available

Read the opening below, then unlock the full answer and practical guidance.

Initially I would check inode usage and open unlinked files, while confirming that both space measurements refer to the application's filesystem...

Upgrade to view official answer

Related Questions