¿Cómo detengo esta pérdida constante de espacio libre?

Estaba ejecutando Ubuntu, como de costumbre, cuando de repente recibí un cuadro de diálogo que decía que solo me quedaban 1,2 GB de espacio libre. Una hora antes, tenía 30 GB de espacio libre.

Eliminé algunas cosas y traje el espacio libre hasta 25 GB. Pero sigue disminuyendo. Traté de eliminar archivos de registro antiguos y truncar archivos de registro y demás, ¡y continúa disminuyendo!

Intenté usar Disk Analyzer para encontrar de dónde provenía toda esta pérdida de espacio libre y eso no funcionó, ya que mostró todo como debería ser. Reinicié y finalmente Ubuntu hizo una comprobación de disco que de alguna manera trajo el espacio libre de vuelta a 40 GB, pero aún continúa disminuyendo unos 10 GB por día. Sigo intentando encontrar nuevas formas de liberar espacio, pero es como un proceso automatizado de disminución del espacio en disco que no puedo detener.

No se que hacer. ¿Cómo puedo encontrar la causa y evitar que mi espacio libre disminuya?

Aquí está la salida de sudo du -sh /var/* ~/.xsession-errors:

13M /var/backups
204M    /var/cache
112M    /var/crash
4.0K    /var/games
503M    /var/lib
4.0K    /var/local
0       /var/lock
9.5G    /var/log
85M     /var/mail
4.0K    /var/metrics
24K     /var/opt
0       /var/run
1.7M    /var/spool
391M    /var/tmp
11G     /var/tvmobili
20K     /var/www
224K    /home/school/.xsession-errors

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/syslogabierto? Usamos el fusercomando:

# fuser /var/log/syslog
/var/log/syslog:      602

Solo un proceso se ha /var/log/syslogabierto. Es el proceso 602. ¿Qué es eso? No nos molestemos con psy grep, pero miremos el /procsistema 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 rsyslogdhaya/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 fusermuchas 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 selectllamada. 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.

Una comprobación de disco liberó parte del espacio, lo que sugiere que este problema (o parte de él) puede deberse a la corrupción del sistema de archivos. Si ese es el caso, entonces debería poder liberar más espacio escaneando y reparando el sistema de archivos. Sin embargo, si la corrupción está ocurriendo perpetuamente (lo que podría o no ser el caso), eso generalmente significa que el disco duro está muriendo. Si sus copias de seguridad (de sus documentos y cualquier otro archivo importante que sería difícil de reemplazar) no están completamente actualizados, haga una copia de seguridad de todo lo importante ahora.

Para verificar y reparar el disco, no se puede montar (al menos no lectura-escritura). Por lo tanto, debe ejecutar la utilidad de reparación desde un entorno en vivo (CD / DVD en vivo o USB). Primero, deberá averiguar el nombre del dispositivo de la partición que contiene sus archivos.

Por lo tanto, en el sistema instalado , ejecute:

mount | grep ' on / '

(Asegúrese de incluir el espacio entre el /y '.)

Obtendrás algo como:

/dev/sda8 on / type ext4 (rw,errors=remount-ro)

El texto anterior, en onel ejemplo de mi máquina, /dev/sda8es el nombre completo del dispositivo para su partición raíz ( /). Anote esto, lo necesitará.

Luego, inicie su computadora desde un CD / DVD de escritorio Ubuntu o una unidad flash USB, como lo que usó para instalar Ubuntu originalmente. (Si se trata de un sistema Wubi, instalado con el instalador de Windows, háganoslo saber. No espero eso, dado lo que ha informado, pero si ese es el caso, el procedimiento será diferente).

Seleccione Probar Ubuntu sin instalar (no Instalar Ubuntu ). Cuando obtenga un escritorio que funcione, presione Ctrl+ Alt+ Tpara abrir una ventana de Terminal. Luego ejecuta este comando:

sudo e2fsck -fkccp /dev/sda8

Pero asegúrese de reemplazar /dev/sda8con el nombre completo correcto del dispositivo para su /partición, tal como lo obtuvo a través del método detallado anteriormente.

Esto puede tardar un rato. Las copciones incluidas en ese comando hacen que escanee la superficie del disco en busca de errores, así como el sistema de archivos (y que marque las áreas malas como malas para que no se usen). Puede dejarlo ccfuera si lo desea (si lo hace, también puede dejarlo fuera k), pero le recomiendo mantenerlos dentro.

Es posible que se le solicite que solucione ciertos problemas, si e2fsckcree que existe una probabilidad significativa de que intentar solucionarlos pueda causar la pérdida de datos. (Esto phace que solucione cualquier problema que esté seguro de poder solucionar sin causar complicaciones).

Le recomiendo que tenga una fuerte inclinación a permitir que repare lo que quiera, ya que solo debe hacerlo después de asegurarse de que sus copias de seguridad estén actualizadas . Si desea que intente incluso soluciones potencialmente peligrosas sin avisarle, reemplácelas ppor y.

Después de esto, reinicie en su sistema Ubuntu y vea si hay espacio libre. Si no es así, o si el problema continúa, comente y edite su pregunta para proporcionar detalles.

este problema se ha resuelto, era el cortafuegos escribiendo toneladas de registros y archivos de codificación de tvmobili