Sin espacio en disco, ¿cuál es la fuente?

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

mientras entraba en pánico buscando respuestas después de lo que parecían edades, el uso disminuyó

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

No he borrado nada hasta ahora y ahora y ahora que estoy escribiendo esto, vuelvo a

/dev/sda1             220G   12G  197G   6% /

¿¿Lo que pasó?? ¿Cómo puedo investigar la causa y establecer las cosas para que no vuelva a suceder? Evito que esto vuelva a suceder

Durante el tiempo de uso del masaje descubrí que el tamaño de la carpeta / var era constante en 1.8 gigas, pero no pude verificar todas las carpetas

editar subido a

/dev/sda1             220G   18G  192G   9% /

* Actualización 2 * Está subiendo de nuevo

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

Y comprobando el comando que me dieron

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

tenga en cuenta el 3.3G para /

Creo que tiene algo escrito en un archivo que se ha eliminado de la unidad pero que aún no ha sido cerrado por la aplicación / servidor, por lo que el espacio permanece asignado en el disco pero no se puede ver dudesde que el archivo se eliminó del sistema de archivos. El lsofprograma enumera los procesos que tienen archivos abiertos. Si tuviera más sistemas de archivos montados y el número no fluctuara mucho, entonces le habría sugerido que tuviera un sistema de archivos montado en la parte superior de un directorio que no estaba vacío (aunque podría intentar umount /var/lib/ureadahead/debugfsasegurarse de que el directorio esté vacío y no hay un montón de basura escrita en el directorio que se esconde debajo de ese punto de montaje).

Si este es el caso, entonces debería encontrarlos fácilmente sudo lsof | grep deleted. lsofincluye (deleted)en la última columna si un archivo se ha eliminado mientras un proceso todavía lo tiene abierto. La primera columna es el nombre del comando, la segunda columna es el PID. Puede obtener una vista más detallada del comando utilizando, pspor ejemplo ps auxww | grep PID, o ps auxwwf | less -Spara ver la lista de procesos en modo "bosque" para que pueda ver de qué proceso proviene ese PID. Una vez que haya rastreado los procesos que contienen archivos gigantes abiertos, puede detenerlo para liberar espacio en el disco y luego descubrir cómo solucionarlo para cerrar el archivo correctamente. La causa habitual de esto es un script logrotate que cambia el nombre / elimina los archivos de registro pero no notifica a la aplicación que lo ha hecho (ya sea a través de una señal apropiada conkill o reiniciando la aplicación), para que la aplicación continúe manteniendo abierto el antiguo archivo de registro.

correr

du -h --max-depth=1 /

Y debería dar una imagen más clara. Si está yendo y viniendo, suena como si se estuvieran creando archivos temporales y luego no se eliminen una vez que se haya terminado, hasta que cualquier proceso que lo esté bloqueando. ¿Qué sistema operativo está ejecutando este servidor y está ejecutando algo en particular?

Parece que el problema es /var/lib/ureadahead/debugfs. Parece que este es un problema conocido, aquí hay un enlace a foros de ubuntu con más información http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . El tl; dr parece ser actualizar y actualizar sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, luego reiniciar. Por supuesto, supongo que está ejecutando 10.04.

Mi conjetura son los archivos de registro; Tenía tantas advertencias "obsoletas" de PHP 5.3 en mis registros de Apache en un servidor de desarrollo que realmente no estaba prestando atención a que masticaba los 8GB de espacio en mi partición var (como una barra lateral al problema: siempre debe poner / var en una partición separada en la que la partición raíz se está quedando sin espacio puede causar problemas de inestabilidad del sistema

Si el espacio se consumió muy rápidamente (no en edades), probablemente sea solo la asignación de archivos.

La causa podría ser un gran intercambio o archivos temporales para alguna aplicación, que se vacían después de su proceso.

Haz un du --max-length=1cuando el espacio se consume mucho.

Si cree que su carpeta raíz está tomando demasiado (3.3 GB) intente ll -a / y publique los resultados.

Parece que /var/lib/ureadahead/debugfspuede ser un arenque rojo. Este es el por qué...

Si bien /var/lib/ureadahead/debugfsexiste en /etc/mtab, no se encuentra en /proc/mounts:

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

El dfcomando parece estar informando exactamente lo mismo para /var/lib/ureadahead/debugfsy/

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Crear un archivo de 1GB en /tmp:

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

Muestra el tamaño reportado en ambos lugares:

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Entonces, parece que el /var/lib/ureadahead/debugfsdispositivo es una pista falsa, ya que solo refleja las estadísticas /. Si se está quedando sin espacio, se debe a algo que llena su sistema de archivos raíz. Verificaría su / var / log primero.

El problema estaba siendo iniciado por una tarea cron que ejecutaba un comando php CLI cada minuto. El código PHP parecía estar atascado en algún tipo de locura de errores atrapados y una cantidad masiva de datos de depuración creciendo a la velocidad del procesador.

Como el código php que se estaba ejecutando tardó más de un minuto, no consideró el trabajo realizado, siguió ejecutándose una y otra vez aumentando la velocidad del crecimiento de los datos (¿temporales?).

La misma tarea se ha estado ejecutando durante casi un mes sin problemas, por lo que no estaba en mi mente como una causa.

Lo extraño es que el script php establece el tiempo máximo de ejecución manualmente

Revisé el php.ini en busca de pistas

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

¡Dice que los valores están codificados de forma ilimitada para la CLI! O_o