Los errores SIGSEGV en PHP aparecen una mañana

Durante unos días libres que tuve, realice una actualización de PHP desde 7.2.12 (aproximadamente) a la ultima versión disponible de PHP: 7.3.1

Todo salio bien en ese momento. Incluso las cosas funcionaban sin problemas, pero eso cambiaría a la mañana siguiente.

Fue entonces cuando este sitio web me arrojo un error 503. Así como otros más en esta VPS corriendo ubuntu.

Al revisar en los archivos de errores, en busca de alguna causa, solo encontraba lo siguiente:

(104)Connection reset by peer: [client XX.XX.XX.XX:XXXX] AH01075: Error dispatching request to : 

AH01067: Failed to read FastCGI header

Al mirar más de cerca, resulto que Apache servia contenido estático sin problemas. Solo las páginas generadas por PHP mostraban el error.

Cuando revise en los registros de PHP, la siguiente línea aparecía múltiples veces:

WARNING: [pool XXXXX] child XXXX exited on signal 11 (SIGSEGV - core dumped) after 30.977656 seconds from start

Este error de SIGSEGV en PHP significaba que había sucedido una Violación de Acceso de memoria (segfault o segmentation fault) por parte de PHP.

¿Cómo era esto posible? ¿Qué lo estaba causando?

Una de las soluciones temporales que encontré fue el usar el siguiente comando:

systemctl restart php7.3-fpm

Pero esta era una solución temporal. Ya que al poco tiempo el problema volvía a suceder. En algunos casos tan pronto como a los pocos segundos.

Esto se estaba volviendo una pesadilla.

Apache2, prefork y el modulo PHP7.3: ¿Origen del problema?

Durante mi investigación, detecte algo que pase por alto cuando actualice PHP a su versión 7.3: Me había agregado un nuevo módulo y cambiado el modo MPM de Apache.

El modo lo podemos ver con el siguiente comando en ubuntu:

apache2ctl -V

¿Eso explicaba el problema?

De lo primero que me percate es que ese nuevo módulo, llamado solamente «PHP7.3», necesitaba que Apache2 corriera en modo Prefork.

No entendí por que de este movimiento, pero no era el cual había configurado en el servidor: Event.

Por lo cual procedí a desactivar PHP7.3 y cambiar Prefork por Event, ejecutando lo siguiente:

sudo a2dismod php7.3
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
systemctl restart apache2
systemctl restart php7.3-fpm

De lo primero que me pude percatar, es que los errores de SIGSEGV en PHP bajaron dramáticamente con esto.

Aunque pronto descubriría que estos estaban lejos de desaparecer.

El error SIGSEGV en PHP da tregua, pero no por mucho

PHP 7.3 funciono de forma normal por algunos días. Pero eventualmente el error volvió a aparecer.

En los registros volvía a ver la señal 11 de SIGSEGV en PHP, lo cual me indicó que el problema tenia muchas posibilidades de seguir apareciendo.

Aunque era menos común, esto significaba que podía suceder en cualquier momento.

Buscando más a fondo, encontré quizá lo más profundo del origen del problema:

segfault at 6c6f4320 ip b4b92b37 sp bfe93df0 error 4 in opcache.so[b4b82000+6d000]

Por fortuna, comencé a notar que no era el único con este problema. Usuarios del panel Plesk también reportaron este problema. E incluso dicha empresa no está recomendando PHP7.3 por el momento.

Lo cual, parece indicar que no hay una solución definitiva por ahora.

Entonces, ¿Cómo solucionar las caídas de PHP?

Como comenté antes, PHP constantemente arroja un error segfault o SIGSEGV el cual interrumpe la ejecución de cualquier recurso dinámico.

Sin embargo, esto se soluciona cuando se reinicia el servicio. Hacerlo manualmente no es una solución aceptable. Y crear un cronjob no me parece una buena idea.

Pero hay alternativas que ya ofrece PHP de forma nativa.

Por ejemplo, nosotros podemos editar el archivo php-fpm.conf (ya que es el modo FPM el cual fallaba para mi) y configurar lo siguiente:

/etc/php/7.3/fpm/php-fpm.conf :
emergency_restart_threshold = 3
emergency_restart_interval = 1h
process_control_timeout = 10s

Con esto, hacemos que PHP este al pendiente por errores. Y cuando sucedan 3 errores en una hora, se reiniciará automáticamente.

De esta forma, el servicio se restablecerá de forma automática sin necesitar nuestra intervención.

Estos valores pueden ser fácilmente cambiados de acuerdo a tus propias necesidades. Solamente recuerda reiniciar el servicio de php-fpm una vez hagas cambios.

Para concluir

Si bien actualmente PHP7.3 parece tener problemas con su sistema de cache interno, con las correcciones adecuadas es posible usarlo sin problemas.

Pero hay algo muy importante que resaltar. Por ahora es mejor el mantenerse en PHP7.2 o tener múltiples versiones instaladas si es posible.

Ya que, a diferencia de la versión más nueva, PHP7.2 está mucho más maduro y este tipo de problemas son mucho más raros.

En mi caso, todavía sigo buscando que es lo que causa el error de SIGSEGV en PHP 7.3, y aunque sospecho que puede causarlo… no tengo una solución definitiva.

Lo que si, espero que esta pequeña guía le sea de utilidad a alguien. Ya que encontrar una solución, aunque parcial, fue una búsqueda de varios días.

Actualización y solución definitiva

Tras haber estado sufriendo el problema de los errores SIGSEGV por mucho tiempo con PHP 7.3, estos finalmente dejaron e suceder.

Sin embargo, la solución puede no ser tan trivial.

Resulta que con PHP 7.4, los errores simplemente desaparecieron. He estado observando los registros de PHP de forma continua por este error desde la actualización, pero esta no ha vuelto a suceder.

Lo cual me hace pensar que el problema no esta presente en PHP 7.4.

Si esta dentro de tus posibilidades, actualizar hacia la versión 7.4 de PHP es lo mejor. No solo trae más características si no que es hasta más seguro.

En caso de que no sepas como actualizar, pregunta con quien lleva tu hospedaje, este debe de poder ayudarte.

The post Error SIGSEGV en PHP 7.3 [Solución definitiva] appeared first on Endless Manifesto.

Cambiar de servicio de hospedaje, para mi, era muy importante. Como parte de crecer y de aprendizaje. En especial por que tenia muy en claro lo que necesitaba. Además de que necesitaba mayor poder de procesamiento.

Es por ello que un VPS (Virtual Private Server) era la solución correcta. Pero es implicaba el ensuciarse las manos un poco. ¿Por qué? Porque en la mayoría de los casos, solo se nos entrega el esqueleto sobre el cual trabajaremos.

El resto de software corre por nuestra cuenta. Igual la seguridad. Es por ello que administrar un Servidor Privado no es para cualquiera. Tienes que saber exactamente lo que estás haciendo.

¿32bits o 64bits para Virtualmin?

Antes que nada, quiero decir que primero probé Virtualmin con Ubuntu 16.04 a 64bits en una VPS con 2GB. No lo hagan. En especial si van a instalar la suite completa.

¿Por qué? Bien, un sistema de 64bits solo se necesita si van a tener un servidor con 4GB de ram o más.

Si tienen uno de 3GB o menos, con una distribución de 32bits tienen más que suficiente. En especial en lo que respecta al uso de memoria.

Las aplicaciones de 64bits usan mucha más memoria. En mi caso, llegue a observar que tanto MySQL y Virtualmin competían por los recursos después de algunas horas. Esto causaba que se necesitara reiniciar el servidor cada que sucedía.

Esto a pesar de tratar de reducir la memoria al mínimo. De todas las aplicaciones.

De entrada, en un sistema 64bits, MySQL usa cerca de 1GB de ram (con el caché incluido). Claro, esto con varios programas y sitios instalados. Contra los 508MB con la misma configuración en un sistema 32bits.

Vaya que hay una diferencia notable. Incluso en los procesos de apache y php.

Igualmente, en el sitio oficial recomiendan 32bits para cuando hay memoria limitada. Cuando es 3GB o menos. Hay que hacer caso.

Instalación de Virtualmin y configuración

El panel lo puedes instalar tan fácilmente como ejecutar esto en la consola de un servidor nuevo:

# wget http://software.virtualmin.com/gpl/scripts/install.sh
# sudo /bin/sh install.sh

Por supuesto, nosotros podemos seleccionar entre otras opciones como instalar una configuración LEMP (nginx) en vez de LAMP (apache). O un servidor con características mínimas.

Pero el LAMP es mejor, en especial si necesitamos correr aplicaciones como WordPress. Aunque todavía, quizá en un futuro, pueda tener un proxy inverso con nginx y apache.

Pero ya veremos.

Regresando a la instalación. La misma es prácticamente automática. Como lo es la de VestaCP. Otro panel que pude probar. Pero a diferencia de Vesta, prácticamente todas las funcionalidades funcionaban out-of-the-box. Lo cual ahorra mucho más tiempo.

En cuanto a la configuración, hay poco que hacerle. Pero quizá lo más importante es el cambiar el modo por defecto de la ejecución delos scripts PHP por apache.

Por ejemplo, la configuración por defecto usa FCGId como modo de ejecución para PHP-FPM. Pero si instalas los paquetes necesarios, puedes usar el modo FPM. Aunque después de estar realizando muchas pruebas… tal parece que el modo por defecto, el FCGId, funciona sin comerse tanta memoria. Lo cual es una buena ventaja en servidores con poca memoria.

Se pueden hacer ajustes finos. Como los que se mencionan en esta página de Linode. Aunque no los he probado, hasta el momento el servidor que he montado ha soportado la carga.

Al menos ya no me muestra la multitud de errores 525, 503 y 520 de antes. Eso ya es ganancia. Junto con la velocidad general adquirida.

Conclusiones sobre Virtualmin y Digital Ocean

Si bien apenas llevo poco tiempo usando Virtualmin, este ha sido un panel que es realmente maravilloso para administrar un servidor. Te permite instalar servidor de correo con un cliente. Servidor LAMP, firewall, administrador de archivos, administrador de base de datos, entre otras cosas.

Esta muy completo.

Esto si, la curva de aprendizaje esta muy empinada. Uno puede tardarse mucho tiempo en conocer todo lo que puede hacer el panel.

No es muy amigable con el usuario. Pero eso no quita que sea muy poderosa.

Otra de las desventajas es que no cuenta con todas las opciones posibles en el frontend. Por lo cual muchas veces necesitarás editar los archivos directamente en el servidor desde la consola.

No es una queja, pero cuando te acostumbras… suele ser más rápido editar las configuraciones directamente en al consola. En vez de estarla buscando entre un mar de opciones.

Pero eso no quita el hecho de que sigo más que satisfecho y recomiendo este panel.

The post Virtualmin en Digital Ocean: Experiencias appeared first on Endless Manifesto.