Si administráis un sitio web que genera una gran cantidad de archivos temporales, como por ejemplo un sitio web de comercio electrónico, puede que en algún momento os encontréis con un error como este que os paraliza la web y, lo que es peor, os impide el acceso por phpMyAdmin:

El error 28 nos está indicando que no tenemos espacio suficiente, como podemos comprobar fácilmente con el siguiente comando:

Pero una simple comprobación nos indica que aún tenemos más de un 40% del disco duro libre, luego el problema no es exactamente ese. Optamos entonces por intentar reparar la tabla en cuestión, sin éxito. La tabla sigue “marked as crashed” y al ejecutar el comando repair se nos muestra un error diferente:

No puede crear un archivo temporal pese a tener casi medio disco duro vacío. Al ser un sitio web con muchos archivos, puede que el problema esté en los inodes (inodos, en español). Los inodes son unas estructuras de datos de Linux (y otros SO) que contienen las características de cualquier objeto del sistema de ficheros, ya se trate de archivos, directorios o enlaces simbólicos. En una web de este tipo y sin la configuración adecuada, puede que el número de inodes crezca y crezca hasta bloquear el sistema.

Para comprobar si este es el caso, ejecutamos df -i, lo que nos devuelve el siguiente resultado:

Ese 100% en /dev/sda1 nos confirma que estamos sobre la pista correcta. Ahora hay que averiguar la ubicación exacta de esos inodes. Para ello vamos ejecutando este comando, empezando por el directorio raíz y profundizando poco a poco, para localizar cuál es el directorio que está saturado.

Esto nos devuelve una lista con el número de archivos de cada directorio. Nos adentramos a cada paso en aquél con mayor número de archivos, cambiando únicamente la ruta del for del comando por la ruta del directorio en cuestión. En nuestro ejemplo, esta búsqueda nos lleva finalmente hasta un directorio de sesiones de nuestra plataforma de e-commerce que contiene más de 76 millones de archivos.

La solución parece sencilla: borrar esos 76 millones de archivos, pero eso no es algo que Linux nos permita hacer con un simple rm * de los archivos anteriores a una determinada fecha.  Son demasiados archivos. En un caso como este, debemos echar mano del útil comando xargs, que divide la lista de archivos en sublistas a las que va aplicando sucesivamente el comando de borrado. Otro detalle a tener en cuenta en este caso es el tiempo de sesión, pues no debemos borrar los inodes de sesiones activas, de modo que el comando queda así:

Y esto es todo. Para un caso como este con varios millones de archivos a borrar, debéis esperar un poco a que la plataforma vuelva a estar operativa.

Es probable que alguna vez os hayáis encontrado con que en vuestro servidor Ubuntu se ha dejado de lanzar la cron de ISPConfig por algún motivo desconocido, y necesitáis lanzarla a mano. Pero antes de hacerlo, es pertinente que activéis el modo de depuración para verificar que no hay ningún error durante la ejecución de la cron.

Para ello, accedemos a nuestro ISPConfig y dentro de la pestaña Servidor, en el desplegable Loglevel seleccionamos el valor Errors.

ISPConfig

Hecho esto, pasamos a lanzar la cron desde la línea de comandos. La instrucción para eso es /usr/local/ispconfig/server/server/server.sh. Al haber activado el modo de depuración, se nos irá mostrando por pantalla cada una de las operaciones, para que aparezcan los avisos pertinentes en caso de que la ejecución de la cron conlleve algún error.

Línea de comandos

Si en un Moodle recién instalado, cuando intentamos añadirle un módulo, plugin o plantilla:

  1. se nos queda en blanco la pantalla,
  2. nos da un error de permisos no válidos,
  3. en el error.log de nuestros logs nos encontramos con este error:

[error]  FastCGI: server “/var/www/XXX/cgi-bin/php5-fcgi-*-80-dominio.com” stderr: PHP message: PHP Fatal error:  Uncaught exception ‘invalid_dataroot_permissions’ with message ‘Invalid permissions detected in $CFG->dataroot directory, administrator has to fix permissions.’ in /var/www/XXX/lib/setuplib.php:1278

Lo único que tenemos que hacer es irnos a la carpeta moodledata, y mirar los permisos de las carpetas que están dentro de ésta. Los permisos de estas subcarpetas y sus archivos deben ser de 777 (según recomiendan en Moodle.org).

Si los permisos son los correctos, o no nos da ese error de permisos no válidos, podemos hacer lo siguiente:

  1. quitamos el plugin, plantilla o módulo.
  2. nos logamos y activamos el modo debug en Moodle
  3. volvemos a colocar el plugin, plantilla o módulo a instalar
  4. volvemos a cargar la web. Nos devolverá un error. Lo más probable es que haya un error de tiempo de ejecución demasiado corto.

Para corregir ese error, lo mejor es ir a php.ini y ampliar el parámetro

[crayon-5b4ec9f6bea18892910939/]