Actualización y los 4 millones de archivos

Un tiempo atrás actualicé un sistema Debian en forma rutinaria y hace un par de días comenzó a producir problemas extraños en las aplicaciones: desde pérdida de sesión al editar páginas web, errores para escribir en las bases de datos, hasta problemas de permisos en los archivos temporales.

El problema resultó ser la temida y oscura: tabla de inodos llena.

# df -i
Filesystem      Inodes    IUsed           IFree IUse% Mounted on
/dev/sda1       5120000 5120000     0        100%   /

Entonces, a salir a buscar dónde estaban los millones de archivos que ocupaban todos los inodos:

# find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
...
3945231  /var/lib/php5/

y resulta que en ese directorio se mantenían unos casi cuatro millones de archivos llamados como sess_dn5m6oc4fcpfo0c95pq1se4rp0.

Aparte de iniciar un proceso de borrado masivo:

# cd /var/lib/php5
# find . -name "sess_*" -print | xargs rm -v

Inicié la búsqueda de las causas de fondo para evitar que el problema se vuelva a repetir en el futuro.

En Debian/Ubuntu el encargado de mantener los archivos de sesiones que se generan en /var/lib/php5 es el script

# cat /etc/cron.d/php5
# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)

que como se puede ver, utiliza la salida de la ejecución de /usr/lib/php5/maxlifetime para determinar el tiempo de mantenimiento de los archivos de sesión de php.

El problema se generó en la ejecución de /usr/lib/php5/maxlifetime que producía el error de al ejecutar por la presencia de la directiva safe_mode en el archivo php.ini:

#  grep safe_mode /etc/php5/apache2/php.ini
safe_mode = On

en razón de que:

42 | WARNING | INI directive ‘safe_mode’ is deprecated from PHP 5.3 and forbidden from PHP 5.4.

Así la actualización a PHP 5.4 hizo que el archivo /usr/lib/php5/maxlifetime dejara de devolver un valor para devolver un error. Entonces el proceso de limpieza, dejó de limpiar y se juntaron cuatro millones de archivos que llenaron la tabla de inodos.

Solución permanente: comentar safe_mode = On en el archivo php.ini.

Listar permisos rwx en octal

Estamos acostumbrados a ver los permisos de los archivos con el comando ls -l con la típica representación de rw-r–r– y generalmente hago la traducción a octal 644 en forma mental.

Pero si necesitamos desplegarlos en octal, tenemos a nuestra disposición el comando stat que soporta dar formato a la salida para ver sobre el estado de nuestro sistema de archivos:

En GNU/Linux que utilizamos stat de GNU Coreutils:

stat -c «%n %a» *
config.cf 644
containers.txt 644
libs 755

En MacOS que utilizamos stat de BSD:

stat -f «%N %Lp» *
config.cf 644
containers.txt 644
libs 755

Felicidades y happy hacking en 2017

Crear archivos grandes

create large files

Varias veces he tenido la necesidad de crear archivos grandes, ya sea para luego darles formato de sistema de archivos y usarlos como imágenes o para llenar espacio en disco. Hasta ahora utilizaba el comando dd, pero hace poco encontré que existen formas múcho más rápidas para hacerlo y que terminan siendo más adecuadas.

dd

Como dije utilizaba el comando dd que está pensado para copiar archivos y, cuando se leen datos desde el dispositivo /dev/zero, se puede crear un archivo lleno de ceros.

dd if=/dev/zero of=archivo.img bs=1024 count=1000000

Página man dd

fallocate

fallocate se utiliza para pre-asignar bloques a un nombre de archivo. Esta tarea se realiza muy rápidamente porque solo se asignan bloques sin datos, por lo que no se realizan operaciones de entrada/salida y termina siendo mucho más rápido que crear un archivo lleno de ceros.

fallocate está disponible desde el kernel Linux v2.6.31 y está soportado por los sistemas de archivos btrfs, ext4, ocfs2 y xfs.

fallocate -l 10M archivo.img

Página man fallocate

truncate

truncate permite ampliar o reducir un archivo a un tamaño especificado. Si el archivo no existe, se crea con el tamaño específico, que es lo que generalmente necesito hacer.

Si un archivo es más grande que el tamaño especificado, se pierden los datos extra. Si un archivo es más corto, se extiende y la parte ampliada está llena de byte cero.

truncate -s 10M archivo.img

Página man truncate

xfs_mkfile

xfs_mkfile permite crear uno o más archivos en sistemas de archivo xfs exclusivamente (lo estandar en RedHat a partir de la versión 7).

El archivo por defecto se rellena con ceros por defecto. El tamaño que se indica por defecto es en bytes, pero se pueden indicar en kilobytes, bloques, megabytes o gigabytes con los parámetros k, b, m, o g, respectivamente.

xfs_mkfile 1240m archivo.img

Pagina man xfs_mkfile

Google filesystem

Mañana jueves 28 de agosto, a las 19:30 horas en el auditorio de la Universidad ORT Centro (Mercedes esq. Cuareim), tendremos una disertación sobre Google filesystem a cargo de mi amigo Mario Bonilla, que actualmente ocupa el cargo de Site Reliability Engineer en Google Dublin.

En la charla, se verán los detalles internos del funcionamiento de Google File System (GFS). GFS es extremadamente exitoso dentro de Google, siendo utilizado como su principal recurso de almacenamiento, en filesystems de varios petabytes distribuídos en miles de equipos. Se verá en detalle la arquitectura de GFS, así como las razones por las que esta arquitectura, combinada con hardware de bajo costo y software libre, es extremadamente conveniente para Google.

En forma independiente, se explicará también el funcionamiento de Google Summer of Code, un programa de la Google Open Source Program Office destinado para que estudiantes universitarios puedan realizar interesantes proyectos de software libre, y además ganar dinero con ello.

Actualmente Mario (aka Miope) es Site Reliability Engineer, responsable por el mantenimiento de la mayor parte del cluster y el almacenamiento de Google, y esta trabajando en interesantes proyectos en pro de la calificación de la próxima generación de sistemas de almacenamiento. Antes de comenzar en Google, Mario fue Administrador de Sistemas Unix en un banco Uruguayo. En 2005, Mario fue parte del equipo fundador de FSFLA (Free Software Foundation Latin America), y formó parte del Consejo inicial. Además, en 1997 compartimos el proceso fundacional del UYLUG (Grupo de Usuarios Linux del Uruguay).

La semana pasada estuvimos juntos en las Jornadas Regionales de Software Libre que se reaizaron en Buenos Aires, y compartimos unas muy interesantes tertulias neerdisticas 😉