Hace poco tuve un problema con un servidor: se quedó sin espacio en disco. Al limpiarlo, empezó la base de datos a dar errores. Fuí al log de MySQL y me encontré con muchas líneas de error, pero el que me llamó la atención me decía que “Incorrect key file for table ‘/tmp/#sql_3c51_0.MYI’; try to repair it”. Básicamente era que no podía ejecutar SQL grandes porque el espacio en /tmp no era suficiente.

Las soluciones al error pasaban por hacer backup de todas las BD, descargártelas, borrar ciertos archivos y volver a restaurarlas, pero yo dudaba de que ese trabajo sirviera de algo. Entonces encontré esta explicación:

Por defecto, MySQL tiene asignado el directorio /tmp del raíz para hacer sus tareas. Cuando la partición raíz está llena, Debian (o Ubuntu en mi caso), crea en RAM una partición /tmp de 1 mega para que MySQL siga funcionando para las funciones básicas, pero no para traerse datos de uan web, por ejemplo. Si hacemos df -h, veremos una línea parecida a esta:

La solución consiste simplemente en borrar esa partición, y volverá a coger el directorio /tmp del raíz. Es decir, hacemos

Y para estar más seguros reiniciaremos el servicio de MySQL. Y todo arreglado.

 

Cuando contratamos un servidor en Linode o Digital Ocean u otra empresa similar, según qué plataformas se instalan en estos servidores y las visitas que reciban, pueden quedarse cortos de memoria swap. En estos casos, podemos ampliar la swap de la siguiente forma, creando un archivo para ello, que lo trataremos como un HDD:

[crayon-5adb573c973d6836196696/]

Con la primera instrucción, creamos en la carpeta root un archivo ‘swapcreadapornosotros’ con un tamaño definido y lo montamos como un dispositivo más. A continuación, hacemos un chmod 600 de esa carpeta,y un mkswap de ese archivo, de forma que indicamos al sistema que a partir de ahora, ese archivo es parte de nuestra swap. Y después, con swapon y el archivo, activamos la swap en el mismo.

Por último, para hacer que después de un reinicio la swap siga ampliándose en el archivo, editamos el archivo fstab e insertamos

[crayon-5adb573c973e0124344212/]

Y listo!

[crayon-5adb573c97647896045440/]

Cuando en un Moodle tengamos foros y aparentemente no salgan sus correos a los usuarios, podemos chequear su funcionamiento abriendo una conexión por terminal y ejecutando el siguiente comando:

[crayon-5adb573c97651215146321/]

Al ejecutarlo, si está todo correcto y no hay nada en cola, saldrá algo así:

[crayon-5adb573c97655135406957/]

Y si por el contrario, hay alguna petición en cola, saldrá así:

[crayon-5adb573c97659118247966/]

Si hay algún problema, el mensaje sería el siguiente:

[crayon-5adb573c9765e185601085/]

Según el error devuelto, tendremos que arreglar permisos, o corregir la ruta de PHP etc.

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:

[crayon-5adb573c97926020134948/]

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

[crayon-5adb573c9792f581455134/]

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:

[crayon-5adb573c97934201207043/]

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:

[crayon-5adb573c97938644400127/]

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.

[crayon-5adb573c9793c773787151/]

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í:

[crayon-5adb573c97940491266978/]

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.

Hace poco, instalando un servidor Ubuntu me encontré con el siguiente error al tratar de instalar un paquete:

[crayon-5adb573c97bd6598682926/]

Aunque había configurado aparentemente bien los repositorios de Ubuntu para la versión que estaba instalando, ese error indicaba que necesitaba corregirlos de alguna forma.

La solución pasó simplemente por pasar los repositorios de restricted a multiverse.

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

Hace poco estaba trabajando sobre un Ubuntu 14.04 LTS Desktop cuando empezó a darme errores icomprensibles: MySQL dejó de funcionarme, no podía levantarlo de nuevo, y otros servicios de la máquina fueron cayendo poco a poco. Decidí reiniciarlo y al hacerlo, empezó mi calvario. Me mostraba la pantalla de logado, era capaz de reconocer si la contraseña era o no correcta, pero no terminaba de arrancar. Después de chequear sistema, HD, arrancar modificando el Grub y todo lo que se me ocurrió y no encontrar nada reseñable, logré arreglarlo y recuperar el sistema intacto haciendo lo siguiente:
Reiniciamos el sistema y mantenemos pulsadas Ctrl + Alt + F3 hasta que podemos logarnos en la shell.
Hacemos un ls -ld /tmp. Así obtenemos los permisos del directorio /tmp.Si todo es correcto, debe salir algo parecido a esto:
drwxrwxrwt 15 root root 4096 Aug 22 09:17 /tmp.

En mi caso lo que realmente tenía era:
d——–T 15 root root 4096 Nov 30 04:17 /tmp

Así que lo que tuve que hacer es darle permisos a /tmp (con un chmod tenemos de sobra) y reiniciar. Y todo volvió a la normalidad. El por qué del error, probablemente fueron las actualizaciones, o algún error puntual en la copia de seguridad que dejó el directorio /tmp con permisos cambiados.