Tienes algunos registros fuera de control. En lugar de eliminar como loco todos los días, encuentre el archivo o archivos de rápido crecimiento y busque dentro para investigar qué puede estar causando esto. Tal vez algún programa está girando en un bucle registrando alguna condición. Desactive ese programa, desactive su registro o intente corregir la condición de la que se queja.
Si un archivo está creciendo ante sus ojos, y no tiene idea de qué programa le está escribiendo, puede descubrirlo fácilmente. Aquí hay un ejemplo. ¿Quién tiene /var/log/syslog
abierto? Usamos el fuser
comando:
# fuser /var/log/syslog
/var/log/syslog: 602
Solo un proceso se ha /var/log/syslog
abierto. Es el proceso 602. ¿Qué es eso? No nos molestemos con ps
y grep
, pero miremos el /proc
sistema de archivos directamente:
# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
Ajá, lo es rsyslogd
. No nos sorprende que rsyslogd
haya/var/log/syslog/
abierto.
No se garantiza que este método funcione. La razón es que los programas no tienen que mantener los archivos abiertos en el interior para escribir en ellos. Supongamos que tiene un proceso que abre un archivo, lo agrega y luego lo cierra. Tendrás una investigación algo más difícil. Podrías correr fuser
muchas veces hasta que por casualidad encuentres el proceso "in fraganti". Ese proceso en sí mismo podría estar entrando y saliendo de la existencia rápidamente. Otro problema es que múltiples procesos podrían tener el archivo abierto, pero solo uno lo está haciendo más grande. En ese caso, puede rastrear sus llamadas al sistema.
# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file: 1234 23459
¡Uy! Dos procesos lo tienen abierto: 1234 y 23459. Veamos qué están haciendo:
# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}
No está haciendo nada, solo bloquea una select
llamada. Ctrl-C para romper el rastro:
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
Mira el siguiente:
# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C
Vaya, esa está escribiendo constantemente. Debe ser el malo. Incluso podemos comprobar que el descriptor de archivo 5 en el que está escribiendo el proceso es, de hecho, el archivo grande:
# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr 3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file
No sospecho que tenga un sistema de archivos corrupto, pero para forzar una verificación completa, no tiene que iniciar un DVD.
En primer lugar, revise la configuración de conteo de montaje máximo de su sistema de archivos. Identifique su partición usando el comando df. Ejemplo en un sistema Ubuntu que tengo aquí:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 18062108 5499320 11645284 33% /
udev 392152 4 392148 1% /dev
tmpfs 159768 768 159000 1% /run
none 5120 0 5120 0% /run/lock
none 399416 200 399216 1% /run/shm
/dev/sr0 43668 43668 0 100% /media/VBOXADDITIONS_4.1.4_74291
Puede ver que el /
sistema de archivos está montado /dev/sda1
. Entonces/dev/sda1
es el dispositivo de almacenamiento de la partición raíz (y la única partición en este sistema en particular).
Veamos algunos atributos de ese sistema de archivos. Esto es seguro aunque esté montado. El comando arroja mucha salida. Aquí hay un extracto:
$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /
[ ... SNIP ... ]
Last mount time: Fri Mar 29 17:45:18 2013
Last write time: Tue Mar 5 09:08:03 2013
Mount count: 22
Maximum mount count: 22
[ ... SNIP ... ]
Oye mira, el conteo de monturas es igual al conteo máximo de monturas. La próxima vez que reinicie, habrá una comprobación del sistema de archivos. Lo importante es que el recuento de monturas es un valor positivo. Si el suyo es cero, cámbielo a un valor positivo como 22 usando tune2fs -c 22 /dev/whatever
. Cero significa que nunca se fuerza una verificación, independientemente de cuántas veces se monte la partición. Los sistemas que se reinician raramente deberían tener valores bajos aquí. Un servidor que se cae una vez al año probablemente podría usar un fsck cada vez que se reinicia. También puede establecer intervalos de verificación basados en la fecha.
Ahora para forzar una verificación, puede anular el conteo real para que sea mayor o igual que el máximo, y luego reiniciar. Eso se hace con el capital C
: tune2fs -C 1234 /dev/whatever
. Ahora parece que la partición se ha montado 1234 veces sin una comprobación, que es mayor que el máximo de uno o dos dígitos.
sudo du -sh /var/* ~/.xsession-errors
por favor? (Esos dos lugares que esperaría explotar si hay algo tonto). De lo contrario, estoy con Eliah; esto es indicativo de problemas de disco. Tómate esto en serio.