Limpiar Inodos Linux al 100%

Buenas, acabo de tener un problema con un servidor en el cual el espacio en disco decía que
estaba casi vacío, pero los inodos me indicaban que la partición estaba llena, impidiendo el
arranque de servicios, que en mi caso particular era PostgreSQL. Revisando me di cuenta que
los problemas con inodos, generalmente son debido a problemas con archivos 0 bytes, lo
cuales no tienen peso pero si ocupan espacio de otra forma.

Básicamente un inodo o i-nodo se utiliza para cada archivo en el sistema de archivos. Así
quedarse sin inodos generalmente significa que se tiene una gran cantidad de archivos
pequeños por ahí. Teniendo esto claro que la pregunta a hacerse es ¿qué directorio tiene un
gran número de archivos?

En este caso, el sistema de archivos donde tenía el problema era /var/ y para solucionar este
problema usé los siguientes comandos:

Primero para evidenciar que los inodos del sistema se archivos se han llenado en la partición
ejecutamos:

df –i

Lo cual nos da la siguiente información:

Filesystem Inodes IUsed IFree IUse% Mounted on

rootfs 655360 60902 594458 10% /
udev 59464 250 59214 1% /dev
tmpfs 63478 187 63291 1% /run
/dev/xvda 655360 60902 594458 10% /
tmpfs 63478 3 63475 1% /run/lock
tmpfs 63478 2 63476 1% /run/shm
/dev/xvdc 655360 251084 404276 100% /var

Viendo esto, y sin saber dónde diantres se están siendo usados los inodos usamos el siguiente
comando para buscar volcar una lista de todos los directorios del sistema de archivos con el
prefijo del número de archivos (y subdirectorios) en ese directorio. Así, el directorio con el
mayor número de archivos aparecerá al final:

find /var -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

la salida es la siguiente:

318 /var/lib/postgresql/9.1/main/base/27925
400 /var/chroot/usr/bin
1830 /var/lib/dpkg/info
202205 /var/chroot/var/lib/php5

Cuando hagan un ls (sin comandos adicionales so pena de que tarden 10 veces más para
mostrar la información) se darán cuenta de que muchos archivos están con 0 bytes,
convirtiéndose de esta manera en archivos parásitos.

Teniendo esto en cuenta buscamos de borrarlos de la siguiente forma

find /var/chroot/var/lib/php5/ -type f -size 0 -print0 | xargs -I{} -0

rm {}
va a tardar, dependiendo de cuantos archivos dispongan, que para llenar los inodos deben ser
bastantes. Cuando terminen.

Vuelvan a usar el comando df –i y verán la magia.

Filesystem Inodes IUsed IFree IUse% Mounted on

rootfs 655360 60902 594458 10% /
udev 59464 250 59214 1% /dev
tmpfs 63478 187 63291 1% /run
/dev/xvda 655360 60902 594458 10% /
tmpfs 63478 3 63475 1% /run/lock
tmpfs 63478 2 63476 1% /run/shm
/dev/xvdc 655360 144847 510513 23% /var

Ahora pude arrancar el servicio y pude respirar tranquilo.

Con este método fácil y practico espero puedan lograr solucionar cualquier problemas de este
tipo.

Inodos al 100%, como liberar…

Problema presentado:
Se deben liberar inodos del servidor:

[root@server root]# df -i
S.ficheros Nodos-i NUsados NLibres NUso% Montado en
/dev/hda1 6203942 6203942 0 100% /
none 5534 1 5531 1% /dev/shm

Solución
Empezamos a borrar los logs:
1. Correos y registros:

[root@server root]# cd /var/spool;

[root@server root]# rm -Rf exim

2. Después de un ataque de spam, todos los archivos quedan en cola dentro

de /root/.cpanel/comet
Para eliminarlos, se debe aplicar el siguiente script.

[root@server root]# /usr/local/cpanel/bin/purge_dead_comet_files

Problema de inodos llenos en Linux

Debido a mi profesión, tengo que tratar con problemas que van surgiendo en el
diario, que gracias al conocimiento adquirido a lo largo de los años y a la ayuda
de la búsqueda de problemas similares en Internet, finalmente he podido
solucionar.

El problema surge cuando tenemos un error y no sabemos de dónde puede

provenir.

En mi caso particular me pasaba lo siguiente:

– El servidor dedicado donde alojo las webs, no me permitía reiniciar el proceso

me daba errores del tipo “no space left on device” , “write failed” y “user
block limit reached”

– Era bastante extraño este error, ya que, el disco duro es de 1TB y

comprobándolo, tenía la siguiente la información:

1 ~ # df
2 S.ficheros Bloques de 1K Usado Dispon Uso% Montado en

3 /dev/md/1 10403064 3252248 6626532 33% /

4 udev 4035092 208 4034884 1% /dev

5 /dev/md/2 958137332 49863180 859986824 6% /home

6 shm 4035092 0 4035092 0% /dev/shm

– Curioso, ejecutando el comando df pude observar que tan solo tenía ocupado
un 33%.

– Indagando, encontré que el fallo se produjo por una saturación de i-nodos,

ejecutando el comando df –i obtuve la siguiente información

1 ~ # df -i

2 S.ficheros Nodos-i NUsados NLibres NUso% Montado en

3 /dev/md/1 655360 655360 0 100% /

4 udev 1008773 5418 1003355 1% /dev

5 /dev/md/2 60366848 910175 59456673 2% /home

6 shm 1008773 1 1008772 1% /dev/shm

– Generalmente esto se produce por la creación de infinidad de ficheros

pequeños dentro del directorio, en este caso, raíz /.

– ¿Cómo encontrar dónde se encuentran dichos ficheros? Ejecutando

1 find . -printf "%i\n" | sort -u | wc -l

– De esta forma obtendremos el número de ficheros de cada directorio,

empezaremos por el principal / y luego por los directorios que haya, hasta
encontrar el que contiene más ficheros.

– En mi caso particular el problema surgió por el proceso qmail, el cual había

generado (y generaba) de forma constante una serie de emails que insertaba
continuamente en la cola de correos (queue).
– Para solucionar este problema, realicé los siguientes pasos:

1. Descargué queue-repair de la web http://pyropus.ca/software/queue-repair/

2. Lo descomprimí, en mi caso dentro del directorio /root/temp/

3. Y cree un script en bash con los siguientes parámetros

1 #!/bin/bash

3 /etc/init.d/qmail stop

4 rm -rf /var/qmail/queue

5 /root/temp/queue-repair-0.9.0/queue_repair.py -c -s 23 --no-bigtodo .

6 /root/temp/queue-repair-0.9.0/queue_repair.py -c -s 23 --no-bigtodo /var/qmail

8 rm -rf /var/log/qmail/lock

9 /etc/init.d/qmail start

De esta forma, cada vez que tengo algún problema con la cola de correo
qmail, ejecutando el script, realiza todos los pasos necesarios para
solucionarlo.

Para comprobar que de nuevo funciona correctamente, utilizo el siguiente

comando para enviarme un correo desde qmail

1 # echo test | mail emailquesea@loquesea.com

2 # tail -f /var/log/qmail/current

Espero que os sirva de ayuda y que encontréis esta solución sin perder tanto
tiempo como el que invertí yo.
Eliminar ficheros por su número de
Inodo
Si alguna vez encuentras en tu máquina ficheros del tipo “??!”, “-aasd/a”, etc. creados
por error, te darás cuenta de que a veces no es demasiado sencillo borrarlo, ya que
contienen caracteres que muchas veces ni siquiera “escapándolos” permite borrarlos.
Para ello, existe una solución, cada fichero tiene un número de Inodo, para
averiguarlo:

[root@localhost] ls -i <fichero>

Ejemplo:

[root@localhost] ls -i *

2781528 index.php 2781559 ??!

el fichero “??!” tiene el número de inodo 2781559, y podemos borrarlo gracias al

comando “find” y su opción “-inum” (inode number):

find . -inum 2781559 -exec rm -i {} \;

Y el fichero ya ha sido borrado.

iNodos al 100% (solucionado)
Les resumo un poquito cual es el inconveniente, tengo una pc con un red hat 9,
tengo suficiente espacio en el disco como para poder trabajar, pero cuando intento
hacer cualquier tipo de actividad, como por ejemplo crear un archivo o iniciar un
servicio como por ejemplo el adsl-start me pone que no hay espacio suficiente en el
disco. Buscando un poquito, con el comando df -i me devuelve el sistema de
ficheros, los Nodos-i, que según tengo entendido sería algo parecido a lo que es la
FAT en windows, esto es lo que devuelve
[root@xxxxx root]# df –i
S.ficheros Nodos-i NUsados NLibres NUso% Montado en /dev/hda1 116224 116224
0 100% / none 5437 1 5436 1% /dev/shm al estar los nodos de uso en el 100%,
no me deja copiar ni crear ningún archivo más. La pregunta es, se puede bajar ese
porcentaje sin tener que borrar archivos. Probé con borrar 5 archivos y me dejo
crear uno solo, pero cuando intente crear el segundo ya no me dejo más....
Alguna sugerencia????
RE: iNodos al 100%
Un inodo es un número que contiene información de cada archivo, cada archivo
tiene por lo menos un inodo y si es muy grande va a tener varios inodos. Lo que te
tendrías que preguntarte es por qué tenes los inodos al 100%. Por más que tengas
mucho espacio libre en disco por ahí tenes muchos archivos chicos que algún
programa te creó, quizás estos sean archivos temporales que no los necesites más,
si es así podrías buscarlos en el directorio "/tmp". Otro directorio que deberías
inspeccionar es "/var/" si tenes una distribución tipo debian en var/apt/archives
tenes todos los paquetes que te bajas de internet con el apt-get.
RE: iNodos al 100%
La verdad que todos los directorios donde podría tener log, mail, o tmp. Los revise
y los fui limpiando. Lo que me parece raro es que este equipo, tiene la misma
instalación que otros 10 equipos más, los instalo de la misma manera por que
funcionan como routers y cliente para armar una vpn. Tiene la misma cantidad de
paquetes instalados y la misma cantidad de scripts que levantan la conexión. Si yo
me guio por lo que me decís acá arriba, si yo borrar 5 archivos, me tendría que
permite crear 5 archivos del mismo tamaño, o al menos 1 archivo con el tamaño
correspondiente a los 5 archivos. Y no me deja, supongamos que yo hago un
"[root#] date > archivo_fecha" después de eso no me deja crear nada más. Tengo
alguna manera de listar todos los archivos de la pc y con el tamaño que tiene c/u?
La verdad que la instalación y configuración del equipo no me lleva más de 2 horas,
pero lo tengo en una ciudad a más de 200 kilómetros de aquí. Y por otro lado me
gustaría resolver el problema. Gracias por sus opiniones.
RE: iNodos al 100%
Bueno, buscando un poquito más, me voy acercando a lo que puede ser el
problema, a ver qué opinan. En el directorio /var/spool/clientmqueue el sendmail
va arrojando archivos, el tema es que yo no uso sendmail para nada en ese equipo
y no se para que estaba el servicio levantado. Ese directorio tiene tantos archivos
que cuando hago un "ls" la maquina queda pensando un rato antes de empezar a
listar los archivos y cuando empieza a listar lo he dejado 3 minutos y no termina...
Como el sendmail no lo utilizo para nada, supongo que esos archivos los puedo
eliminar sin ningún problema. Voy a esperar al lunes a ver si alguien me dice lo
contrario, por el momento detuve el servicio de sendmail como para que no siga
arrojando archivos. Saludos
RE: iNodos al 100%
Bueno, por suerte era al final lo que te decía, sino hubiera sido mucho más
complejo encontrar el problema. Supongo que ahora una vez borrados los archivos
debes tener menos porcentaje de inodos. Comenta después cómo te fue por más
que lo hayas solucionado.
RE: iNodos al 100%
Solucionado el problema de los inodos, borrando los archivos baje un 60% los
inodos. Ahora esta no es la solución definitiva, el tema es el siguiente todos estos
archivitos de esta carpeta son mails, hice un cat de uno, y es un mail que se manda
root así mismo para informar x acción. Todos estos mail son los que se van
agregando al archivo /var/spool/mail/root, ese es un único archivo que va
creciendo en tamaño. Esa carpeta /var/spool/clientmqueue, me parece que es la
cola de los mail cuando un mail no se puede entregar se almacena aquí. Los
problemas a solucionar serían los siguientes:
1- porque no se están entregando correctamente esos archivos...
2- se puede de alguna manera deshabilitar que se envíen estoy mail...gracias.