Algo se fagocita mi espacio de disco duro.
soulchainer at
EDITO: YA DÍ EXACTAMENTE CON ELLO.
===================================================================================
Curiosamente, el du que puse no me sirvió de mucho, porque claro tenías que poner du -ah, ZOPENCO. Si no, no cuentas también archivos... Y estaba claro que era un log, una vez sabido lo que daba el error xD.
Concretamente, he aquí el culpable:
-rw-r--r-- 1 miusuario users 113G mar 18 17:34 .qtile.log
Zasca. 113G hermosotes de log de los cojones xD.
Gracias por la ayuda, gente :3.
===================================================================================
No es cosa de cachondeo, ¿eh?
Me di cuenta de esto hace un par de días. Al principio pensaba que eran cosas mías, que quizás es que
lo había copado realmente con mi uso normal... Pero creé espacio, borrando archivos viejos, para comprobarlo:
14:42 $ df
S.ficheros Tamaño Usados Disp Uso% Montado en /dev/sda3 60G 8,6G 51G 15% / dev 3,9G 0 3,9G 0% /dev run 3,9G 908K 3,9G 1% /run tmpfs 3,9G 0 3,9G 0% /dev/shm tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup tmpfs 3,9G 43M 3,9G 2% /tmp /dev/sda2 463M 43M 412M 10% /boot /dev/sda4 57G 5,3G 51G 10% /VMs /dev/sdc1 917G 806G 65G 93% /Multimedia /dev/sdb5 903G 839G 18G 98% /home /dev/sdb6 15G 6,7G 7,9G 47% /var tmpfs 789M 52K 789M 1% /run/user/1000 16:31 $ df
S.ficheros Tamaño Usados Disp Uso% Montado en /dev/sda3 60G 8,6G 51G 15% / dev 3,9G 0 3,9G 0% /dev run 3,9G 908K 3,9G 1% /run tmpfs 3,9G 0 3,9G 0% /dev/shm tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup tmpfs 3,9G 43M 3,9G 2% /tmp /dev/sda2 463M 43M 412M 10% /boot /dev/sda4 57G 5,3G 51G 10% /VMs /dev/sdc1 917G 806G 65G 93% /Multimedia /dev/sdb5 903G 857G 0 100% /home /dev/sdb6 15G 6,7G 7,9G 47% /var tmpfs 789M 52K 789M 1% /run/user/1000 JODER. No me digas que no es un canteo. Lo peor es que no sé qué mierda es exactamente la que está generando este consumo exponencial de espacio. Ni a dónde narices va ese espacio. Como podéis ver, es sólo en la partición /home . Tenía unos servicios para montar en ram, con copia en
disco, los perfiles de los navegadores, sus cachés y alguna cosilla más (psd y asd). Pero los desactivé ayer...
Y esto sigue ocurriendo xD. Ahora mismo he vuelto a hacer unos gigas de espacio y un du -h --time | sort -h > espacio.txt
Y a esperar un rato y luego a hacer otro y un diff, para ver al menos qué es lo que ha cambiado drásticamente de espacio en este tiempo. No me apetece reinstalar todo, la verdad ¬_¬ Quiero saber de dónde viene esto. Y... iba a decir que no había visto ningún proceso raro... pero acabo de ver tres que estaban al 100%... y que son, precisamente, de lo que tenía sospechas que podía causar el problema (más que nada porque es el software reciente que he estado utilizando). Uno era Atom y el otro Qtile.
El primero lo descarté hace unas horas también. Pero vamos, me acabo de dar cuenta, como decía, que tenía varios procesos python corriendo al 100% ¬_¬. A ver si al haberlos cerrado esto desciende xD. Qtile tiene un script para testear cambios en Qtile, que te crea un entorno X dentro de tu entorno X (para que no se te vaya todo a la mierda si cometes un error en la configuración). El caso es que cada vez que cerraba ese servicio, se cerraba con errores y tenía que matar el servicio... En teoría. Pero como he estado matando la terminal bash en la que se ejecutaba... creo que la aplicación se quedaba en segundo plano y me ha estado ocupando espacio a mansalva en algún lado... xD Y va a ser eso, porque he observado que, a pesar de que estoy al 100% de capacidad de nuevo (cuando paré los procesos python ya había ocupado de nuevo todo eso), desde que los he matado se ha estancado y ya no me come el espacio que me queda 5.2GB. Cruzando los dedos por que sea eso xD. Será cuestión de no usar el puñetero proceso... O, sabiendo que es por esto, buscar dónde está el error/reportarlo.>> coyote:
Se autoregenera, por eso la cosa de ponerlo en un cron, para que cada X tiempo lo mande a mejor vida.
Ya hombre, sé lo que hace un cron y cómo funciona la recetilla: de forma periódica, según el cron (horario, diario, semanal...), borrará todo el contenido de .xsession-errors, para evitar que no se desmadre en espacio :p.
A la postre, estás haciendo parte de lo que hace logrotate a manopla.
Lo que yo decía es que si tienes eso activado, y se genera cierto tipo de error, pues igual te dificulta un poco dar con él, ¿no?
Es decir: yo me he dado cuenta de que esto estaba ocurriendo por el consumo de espacio anormal. Con el logrotate, pues el problema no me habría afectado igual. Pero seguiría estando :).
Y es posible que no me percatara de que existe el error siquiera, hasta después de bastante tiempo. Aparte del consumo de espacio anormal, el sistema no daba muestras de problemas. Y hubiera tardado más tiempo en chequear htop, por ejemplo. Y sin estos problemas, pues tampoco tendría motivos para mirar el log de qtile, porque «todo funciona bien». Se autoregeneraría el error, pero no me serviría de nada, porque no lo revisaría.
@Panko Me acabo de fijar de que baobab (pero creo que también Filelight) tiene un pequeño defectillo: te dice gráficamente qué carpetas ocupan más. Y eso está bien... Pero, ya que están y puesto que sólo hace eso el programa (es un programa muy especializado), podrían estirarse y extenderlo también a nivel de archivo. No ya por mí, sino por quienes la consola ni pa.
Si te indica el tamaño sólo a nivel de carpeta cuesta trabajo encontrar dónde está realmente el problema en muchas ocasiones. Como en este caso. Era un archivo de log que estaba en el directorio raíz explorado. Como sólo te da el tamaño total del directorio raíz, y este directorio tiene subdirectorios, no sabes si el espacio de más está en el directorio o en alguno de los muchos subdirectorios. Bueno, obviamente si sólo tienes dos directorios dentro del directorio raíz es fácil deducirlo a simple vista. Pero si tienes cientos de directorios dentro del directorio padre... ponte a sumar sus respectivos pesos, para ver si hay diferencia y, así, el problema está en el padre o no. En resumen: que sirve para ver qué pesa cada carpeta padre... pero en ningún momento sabes qué pesan los archivos de cada subcarpeta, sin incluir a sus carpetas contenidas.
Mejor para estos casos una lista más exhaustiva.
Hombre una lista más completa si que ayuda si, pero si mal no recuerdo, con baobab puedes llegar al archivo, ya que la igual que filelight, te permite ir "navegando" y llegar al archivo que te interese:
De todas formas, viendo que ya has encontrado que era, mejor que mejor ;)
soulchainer likes this.
@Panko Uy, sí xD. Tienes razón >_<. Lo miré, pero se ve que no atiné a verlo :þ.