Nos pasó en un proxy o mailserver y nos estábamos volviendo locos de por qué no había espacio de escritura si tenía un montón hasta que dimos con los amigos inodos...
Más de uno va a aparecer por acá en buscando el error a futuro
Linux: Que no se te llenen los inodos disponibles
Tenía unos problemitas en el servidor del blog ¿Qué cuernos pasaba? Primero Nginx me tiraba error 500 al subir archivos pero no quedaba claro qué error era, en los logs no había nada.
Luego de reiniciar todos los servicios volvió al ruedo pero noté otro problema: no podía actualizar el servidor, me tiraba un error que nunca había visto en pleno apt update.
28: No space left on device error
¿Qué sucedía?
Si no hay inodos disponibles es la muerte, para verlo:
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 491109 310 490799 1% /dev
tmpfs 494072 429 493643 1% /run
/dev/sda1 2560000 2560000 0 100% /
tmpfs 494072 1 494071 1% /dev/shm
tmpfs 494072 4 494068 1% /run/lock
tmpfs 494072 15 494057 1% /sys/fs/cgroup
Oh, mamita, tantos archivos tengo en el servidor? Luego recordé que el maldito webserver mete los temporales de PHP en /home/usuario/tmp y... nunca los borra, quedan ahí
Ahora bien, un rm * te va a dar un error del tipo "Argument list too long" si intentás ejecutarlo, y a mano uno por uno sería la muerte lenta, así que encontré otra forma de borrar usando find y llamando a rm no tantas veces como para volverse ineficiente archivo por archivo:
find . -maxdepth 1 -type f -print0 | xargs -r0 rm -f
Ahí logré, luego de un buen rato ya que es un proceso leeeeento borrar tantos archivos, eliminar suficientes mini archivitos temporales inútiles que crea PHP y que por alguna razón, que deberé googlear, no borra.
Borré, en total, unos 2.385.858 archivos temporales (puse los puntitos para mostrar lo bestial que era) que no deberían haber existido !!! Es el único servidor en el que me sucede así que tendré que ver qué config perdida de PHP está provocando eso.
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 491109 310 490799 1% /dev
tmpfs 494072 429 493643 1% /run
/dev/sda1 2560000 174142 2385858 7% /
tmpfs 494072 1 494071 1% /dev/shm
tmpfs 494072 4 494068 1% /run/lock
tmpfs 494072 15 494057 1% /sys/fs/cgroup
Otros posts que podrían llegar a gustarte...
Comentarios
-
-
ja, puede suceder, es algo que había aprendido hace como 30 años en las primeras versiones de Linux, al instalar tenías que aclarar (antes de formatear) cuántos inodos querías. Como si uno supiera cuántos archivos iba a tener en el futuro. Luego me olvidé completamente de eso y hoy en día ningún instalador te lo pregunta. Aquí la respuesta: si tenés muchos mini-archivos servía
-
Me pasó algo parecido con una máquina con Windows 10 que andaba muy lenta. Di muchas vueltas hasta que logré descubrir con un programa para ver fragmentación, no recuerdo con cuál, que había una carpeta con alrededor de 1,5 millones de archivos. No estaban todos juntos, era una rara estructura de directorios también de temporales que me tomó horas borrar porque Windows borró uno por uno pese a que le decís que mate la carpeta contenedora. Extrañé el viejo y violento deltree del DOS.
-
find+xargs es un gran combo, pero te recomiendo tambien que pruebes find -exec que está muy bueno.
find . -type f -exec rm \{\} \;
Para los que hacemos cosas raras y tenemos millones de archivos, no he encontrado forma mas rápida para borrarlos.
-
Justo hace unos días leía acerca de los inodos: cuando se inicializa el disco para aceptar datos, se establece un número fijo de inodos por partición. Esa será la máxima cantidad de archivos, de cualquier tipo (incluyendo directorios y links simbólicos por ej) que pueden existir al mismo tiempo en esa partición.
Sobre la propuesta de Guille:
find . -type f -exec rm \{\} \;
agrego que usando -delete (en lugar de -exec rm) podría ser aún un poco más rápido haciendo que find ejecute el borrado sin lanzar un proceso externo.
El piping de find con xargs tampoco tiene ese overhead de spawnear un proceso nuevo por cada archivo.
-
Algo similar me pasaba con mis camaras ip q pasan por FTP a un servidor rpi imagenes, si en el dia habia muchas, en el proceso de backup no las borraba y quedaban todas ahi.
La del find la conocia, la otra es montar el /tmp a alguna particion mas chica q sea mas facil formatear.
Sino manda el /tmp a dev/null
-
La otra, mete un Cron Job asi cada tanto tiempo volas lo del tmp.
Tipo tu SLA sobre lo q esta en tmp es 1 semana, lo moves y despues lo borras
-
Este artículo plantea una solución bastante elegante al problema de espacio en servidores: https://www.microsiervos.com/archivo/internet/truco-archivo-vacio-8-gb.html
-
A la fuerza lo aprendí con Gentoo. Al usar una partición pequeña muy fácil se llenan los inodos. No se puede escribir nada más. Dicen que usando "mkfs.ext4 -T small" al momento de formatear se soluciona.
-
A nosotros nos pasa algo parecido con Jenkins, se la pasa creando archivos winstone*.jar en el directorio C:\Windows\TEMP
El archivo se genera cuando hay un error y Jenkins intenta relanzar el proceso con problemas.
Todavía no encontramos que es lo que falla, así que seguimos borrando archivos .jar del temp a mansalva