Cómo saber por dónde se está llenando el disco del servidor y cómo liberarlo

Hace poco hemos tenido un problema bastante serio el los discos de producción. Se llenaban y no sabíamos qué ficheros son los que aumentaban. Durante varios días el comando: 

root@webserver1:/# du -sh /.
2.4G    /.

pero al ejecutar el comando:

root@webserver1:/# df -h
Filesystem    Size  Used Avail Use% Mounted on
/dev/sda1     5.2G  4.9G     0 100% /

¿Y por qué hay esos 300MB de diferencia?

Esos 300MB de diferencia son el ~5% que reserva el sistema operativo para que root pueda hacer escrituras en disco sin que reviente la máquina por no poder escribir en disco. Un pequeño margen de contingencia.

¿Dónde están esos 2,7GB que falta?

Revisando todas los directorios posibles no mostraban ningún candidato. Por eso ejecutamos el comando:

lsof

Este comando permite ver qué procesos son los que están escribiendo a disco. Jugando un poco con él y mandándo el resultado a otros procesos se puede analizar qué ficheros son los más grandes o los que más crecen. Con el siguiente comando vemos cuales son los 50 procesos que escriben a fichero ordenados por tamaño de fichero descendiente:

sudo lsof -s | awk '$5 == "REG"' | sort -n -r -k 7,7 | head -n 50

El resultado fue ver un fichero del proceso varnishncsa que estaba escribiendo a /var/log/varnish/varnishncsa.log.1, pero estaba como (deleted). Cuando un proceso está deleted es que está pendiente de ser borrado, pero... ¿por qué no se borra? Con el siguiente comando vemos qué PID está escribiendo en ese fichero:

lsof -nP  | grep varnishncsa.log.1

Vimos que el PID era el 1178. Ejecutamos el comando siguiente para ver cómo se estaba llamando al proceso

ps -ef | grep 1178

Y sorprendentemente vimos que era un error del script.

109       1178     1  0 Jun19 ?        00:14:30 /usr/bin/varnishncsa -a -w /var/log/varnish/varnishncsa.log -D -P /var/run/varnishncsa/varnishncsa.pid}

Vimos que no se está pasando correctamente el PID al proceso y pro eso nunca puede terminarlo. Además, es curioso. Las gráficas del munin comienzan a dar alertas y picos desde el 19 de junio. Fecha desde que el proceso está activo.

Corregimos el fichero, matamos el proceso malo y volvemos a levantar los logs de varnish:

kill 1178
/etc/init.d/varnishncsa restart

Al ejecutar un df, ya nos aparecen 2,7GB libres.

Otro triunfo más a la cantidad de procesos que tiene Linux y la potencia del caracter "|", que permite sacar potencia descomunal a todos esos procesos.