Anécdota: ¡Out of Memory! ¡Sacrifiquen a los niños!

Esto puede ser una lección sobre como las copias de respaldo pueden salvar vidas.

Introducción

Debido a diversas circunstancias, actualmente tengo dos instancias VPS de idénticas características, cada una destinada a diferentes propósitos que en la practica resultan difusos; una para experimentos, otra para servicios web persistentes(paginas, blogs, herramientas)

CaracterísticaCantidad
CPU1 vCPU compartido
RAM1 GB
Disco Duro25 GB disco duro (no SSD)
Droplet ultra básico en Digital Ocean. Al momento de escribir este post, su precio es de $5 mensuales.

Yo no tengo experiencia administrando servidores de forma profesional, pero a medida que he ido aprendiendo cosas, he caído en cuenta de que es necesario tener tanto una IP publica, como un equipo permanentemente conectado a la red, para lograr algunas cosas así que he ido aprendiendo cosas nuevas vez tras vez. Algunas, a costa de todos mis datos almacenados.

La historia de hoy comienza con un error común, que he subestimado al pensar que no pasaría nada:

Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Failed with result 'exit-code'.
Sep 29 12:52:46 archvb systemd[1]: Failed to start MariaDB 10.4.8 database server.

Este error se solucionaba simplemente reiniciando el servicio, pero esta vez, en lugar de encender el servicio, la respuesta fue esta:

Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

Este error no me resultaba nuevo puesto que también es un error normal, pero resultaba inesperado debido a que al volver a intentar reiniciar el servidor, salía de nuevo el mismo error. Algo no estaba yendo bien.

Mi falta de experiencia me condujo a hacer lo mismo que incluso un profesional haría; buscar en Google.

Por supuesto, Google me respondió de la misma forma fatalista como lo haría con una persona preocupada por su salud, solo que en mi caso, todas las soluciones pasaban por borrar la base de datos por completo e iniciar de cero. Terror y depresión instantánea.

Dado que esa instancia la utilizo para hacer experimentos, no hay muchos datos que valgan la pena ahí. A lo mucho los Logs del sistema domótico y los del bot para descargar música, que en general solo es información estadística (que ya perdí en otro evento catastrófico anterior). El problema era que también cree una instancia de Nextcloud, especialmente complicada de mantener.

Entre practica y practica le había tomado cariño y agregando plugin, empecé a agregar datos que puedo rescatar sin problema alguno. Lo complicado era volver a configurar todo Nextcloud de cero.

Busque en los logs del sistema tratando de entender lo que sucedía, pero no he habilitado un log de archivo por parte del servicio. Por supuesto, la carpeta estaba vacía.

Echándole un ojo al dmesg, encontré este mensaje:

[11668880.114121] Out of memory: Kill process 25000 (mariadbd) score 96 or sacrifice child
[11668880.118537] Killed process 25000 (mariadbd) total-vm:1085072kB, anon-rss:97060kB, file-rss:0kB, shmem-rss:0kB

Esta información solo confirmaba mis sospechas, pero seguía sin dar con una solución. Decidí entonces apagar todos los servicios para empezar a borrar los archivos como decían las instrucciones. Hasta que se me ocurrió intentar por ultima vez levantar el servicio de mysqld. ¡Y se levantó!

A salvo. ¿Ahora que?

No es la primera vez en la que mi servidor cae. Pero si es la primera en la que lo hace tras optimizarlo y mimarlo tanto, por lo que pensé que lo mejor seria realizar un respaldo regular de las bases de datos para empezar. ¿Pero donde?

  • Es posible crear una tarea programada con CRON para extraer una copia de seguridad en el mismo servidor, pero ¿de que serviría si esta cae junto a el?
  • Para empezar, de todas formas, comenzare haciendo una copia de seguridad local regular.
  • Es posible, mediante SSH, crear una copia de seguridad en un equipo físico, también con CRON. Hacerlo de forma regular permite poder restaurar hasta algún punto en el que no haya arruinado algo al travesear con las configuraciones.
  • Debo investigar si es posible utilizar otros servicios en la nube para crear respaldos. Tal vez Google Drive o OneDrive, puesto que tampoco tengo algo tan valioso como para pagar un servicio en la nube.
  • Y por supuesto, Todos los respaldos deben ser automáticos. Hacerlo de forma manual es probablemente mas inseguro que no hacerlo.

Consideraciones

Por el momento estoy investigando como hacer respaldos regulares, Locales, pero regulares, utilizando el cliente de consola MySQL y el automatizado de procesos CRON. Y realmente me esta gustando CRON. No entiendo por que le tuve tanto miedo si ha sido tan fácil de usar. Aunque tengo que conceder que todo lo que se maneje por consola es aterrador y mas si es poco o nada intuitivo.

Incidente: Colapso de instalación de WordPress al actualizar Jetpack

A veces es fácil olvidar que los programas que utilizamos a diario son escritos por humanos, así que nos suele tomar por sorpresa cuando estos fallan. Se nos suele advertir que hagamos copias de respaldo de nuestros datos, pero el engorroso proceso para restaurar estos datos, hace que descuidemos toda medida preventiva y todo va bien, hasta que empieza a ir mal.

El caso de hoy es uno que me sirve de advertencia sobre las actualizaciones automáticas. En general funcionan bien, pero pueden haber sorpresas. Incluso WordPress nos lo advierte cuando las activamos. En mi caso, he hecho caso de la advertencia, activándola únicamente para la extensión que menos creí posible que falle; Jetpack.

Si, es cierto que las actualizaciones de Jetpack suelen estar cargadas de nuevas funcionalidades, pero no era difícil confiarse. Especialmente cuando se lidia con otros problemas, que se suelen resolver con un solo click.

Usualmente resuelvo los problemas del servidor luego de echarle un ojo a los logs del sistema y reiniciar los servicios, pero esta vez no tenia tiempo asi que solo reinicie los servicios sin revisar los logs y me olvide del asunto. Entonces una hora luego, me aparecio este mensaje:

El sitio estaba una hora caído. Mi pequeño blog no tiene muchas visitas y (por ahora) no esta monetizado, así que no me preocupaba. Volví a reiniciar los servicios y continúe resolviendo otros problemas.

La notificacion de que el sitio continuaba caido me atormentaba hasta que por fin tuve tiempo para dedicarle al servidor y comence el diagnostico.

Primero, revisar que mensaje de error muestra el navegador:

Ha habido un error critico en esta web. Si los servicios estuvieran caídos, el error debería ser de conexión rechazada, así que no era cuestión de los servicios.

Lo segundo a hacer es acceder a la consola del servidor y buscar en los logs algún patrón que parezca sospechoso en el log de errores e /var/log/apache2/error.log y encontré lo siguiente:

PHP Fatal error:  Uncaught Error: Failed opening required '/var/www/interlan.ec/wp-content/plugins/jetpack/jetpack_vendor/automattic/jetpack-waf/src/../rules/allow-ip.php'

Este error no tiene misterios. Lo único que habría que hacer era desactivar el plugin de Jetpack para resolver el problema y reinstalarlo. Un plan perfecto, sin fisuras.

Desafortunadamente era imposible entrar al panel de administración de wordpress.

Mi otro blog pasó por exactamente el mismo problema, pero a diferencia del primero, alcanzó a enviarme un enlace al modo de recuperacion que existe desde la versión 5.1 de WordPress, así que al usarlo, bastó con desinstalarlo y reinstalarlo. Esta es una funcion muy util, si el colapso da el tiempo a mandar el correo con la ulr de rescate.

En el caso de mi blog principal, la URL no fue enviada, asi que tuve que buscar el plugin y borrarlo manualmente, con lo que recuperaría el control y volvería a abrirlo al publico.

Por supuesto, fue necesario algo de limpieza adicional para que todo vuelva a esta en orden. Al menos por un tiempo.

Cuando otra vez colapso con el mismo problema, habia una tercera cosa que quedaba por hacer para entender lo que estaba pasando. Recurrir a google.

Una de las cosas que mas me fastidia del internet actual es que la gente ya solo hace consultas en redes sociales, por lo que buscar en google puede dar resultados muy antiguos, de la epoca en la que los foros publicos estaban mas activos.

Minar preguntas en stack overflow llevaria mucho tiempo, asi que tras borrar jetpack otra vez, abri el instalador de su plugin y me encontre con que habian sacado una nueva version, apenas una hora antes. Era evidente de que ellos estaban consientes del problema que habían causado.

El unico bug que arreglaron era justamente uno sobre mi problema actual:

Firewall: prevent sites from crashing when updating Jetpack versions due to a missing generated file.

Explorar los comentarios fue suficiente para saber que no era el único con el problema y tras deleitarme un poco con las quejas de otros, decidí que lo mejor seria dejar deshabilitado jetpack hasta que salga una nueva actualización que corrija lo que la actualización para corregir un problema, había dañado.

Por supuesto, resolver este problema me ha enseñado algunas lecciones y espero que si alguien tiene el mismo problema, se pase por mi solución antes de intentar resolverlo con medidas desesperadas.

A %d blogueros les gusta esto: