Buenos dias a todos,
Ya sabeis que Microsoft ama Linux, las Open Sources, etc., Y mas si se pueden desplegar desde Azure 😉 . Yo si que amo a Azure. Que pasada.
Últimamente he tenido que tratar con problemas sobre servicios que corren en diferentes versiones de Linux que podemos desplegar en Azure (ver aqui), CentOS, Debian, Ubuntu, SUSE, Redhat, etc….
Hoy, último dia de noviembre, me centro en un extraño problema del que solo tenía la siguiente evidencia: En mi servidor web me aparecian errores del tipo “no space left on device” , “write failed” y “user block limit reached”. Detalle extraño ya que, el disco es de 1TB y comprobándolo, tenía la siguiente la información:
| S.ficheros | Bloques de 1K | Usado | Disponible | Uso% | Montado en |
| /dev/md/1 | 10403064 | 3252248 | 6626532 | 33% | |
| udev | 4035092 | 208 | 4034884 | 1% | /dev |
| /dev/md/2 | 958137332 | 49863180 | 859986824 | 6% | /home |
| shm | 4035092 | 0 | 4035092 | 0% | /dev/shm |
Como podeis ver, ejecutando el comando df pude observar que tan solo tenía ocupado un 33%. ¿Por qué me aparecian esos errores de espacio y limitaciones?
Aqui es donde viene la labor de «detective» (jejejeje, es broma) y buscando errores similares encontré que el fallo se produjo por una saturación de i-nodos ,
¿Qué son los inodos? pues son estructuras de datos empleados en sistemas Linux y Unix que contienen información sobre los ficheros. Os habeis quedado igual ¿verdad? Quedemonos con el concepto de que cada fichero se identifica por un número de inodo. Este número es único dentro de todo el sistema de ficheros. De todas maneras, aqui os dejo unos links:
Echemos un vistazo a ver cómo están nuestros inodos. Ejecutamos df -i
| S.ficheros | Nodos-i | NUsados | NLibres | NUso% | Montado en |
| /dev/md/1 | 655360 | 655360 | 0 | 100% | / |
| udev | 1008773 | 5418 | 1003355 | 1% | /dev |
| /dev/md/2 | 60366848 | 910175 | 59456673 | 2% | /home |
| shm | 1008773 | 1 | 1008772 | 1% | /dev/shm |
Here we go!!! Aqui está el problema. Normalmene esto ocurre por la creación de infinidad de ficheros pequeños dentro de un directorio, en el caso de mi servidor web, estaba claro que era en en la partición montada en el raíz /.
Y ¿Cómo encontrar dónde se encuentran dichos ficheros?En este caso ejecutamos el siguiente comando:
find . -printf «%i\n» | sort -u | wc -l
De esta forma obtendremos el número de ficheros de cada directorio, empezando por el raiz y, posteriormente, en los subdirectorios, hasta encontrar la ruta d
e los mil y un ficheros pequeños: /opt/bitnami/apps/wordpress/tmp. Ah!!!!! mi WordPress. Ah!!!! el repositorio Bitnami con IaaS desplegadas y configuradas por defecto!!!!!
Bien, para corregir este problema, creamos una tarea en el crontab del usuario root para que se ejecute todos los días a las 00:01, que busque y elimine ficheros más antiguos de 30 días en la ruta /opt/bitnami/apps/wordpress/tmp .
root@vmwebsrvwp01:~# crontab -l|grep -v \#
01 00 * * * /root/remove-tmp-bitnami.files.ksh > /root/remove-tmp-bitnami.files.LOG 2>&1
el hecho de buscar y encontrar un post de @jabenitezdev, con un problema idéntico al mio, escrito en su blog, me centró el problema y, sobre todo, en la resolución, muchas gracias por compartir 😉
Agradecer y dedicar este post a mis antiguos compañeros de Capgemini, David, Alex, Ivan, Beatriz, Angel, Jose Luis, Christian, etc. Muy buenos momentos y muy buena gente. Espero veros pronto.
Besos y abrazos.