Reciclador de procesos idle php-fpm para Core-Admin -- WebhostingManagement

#1

Actualización (octubre de 2026)

  • El reciclador ya no actúa sobre pools pm = ondemand, que es el modo con el que Core-Admin crea todos los pools. En esos pools php-fpm ya cierra él mismo los procesos ociosos.
  • Si en la máquina no hay ningún pool con otro modo (dynamic, static), el monitor no se arranca: no hay nada que reciclar. El cron de supervisión se mantiene y lo arrancará solo si en el futuro aparece un pool con otro modo.
  • Cuando recicla un proceso lo hace con una parada ordenada (SIGQUIT) en lugar de SIGTERM: si el proceso ha llegado a aceptar una petición, la termina antes de salir.

El motivo se explica en el apartado 4.

1. Introducción

A continuación se describe el monitor de procesos php-fpm idle que proporciona Core-Admin y que permite:

  • Retirar/reciclar procesos php-fpm en estado idle tras un tiempo sin hacer trabajo útil (usualmente 60 segundos), en pools cuyo gestor de procesos no los cierra por sí mismo (pm = dynamic o pm = static).
  • Ayudar a contener el uso de memoria consumida por procesos php-fpm en el contexto de máquinas con webs pesadas o webs con mucha visita debido a bots y similares.
  • Ayudar a reducir el número de eventos OOM killer debido a que se obtiene una mayor media de memoria disponible (al reciclar antes debido a actividad observada).

En los pools pm = ondemand (los que crea Core-Admin para cada alojamiento) este trabajo ya lo hace php-fpm: cierra cada proceso que lleva pm.process_idle_timeout (30 segundos) sin recibir peticiones. Por eso el reciclador no los toca.

2. Funcionamiento

  1. Arranque: con un core-admin actualizado, se puede activar el monitor ejecutando:

    # ARRANQUE:
    >> crad-webhosting-mgr.pyc --start-recycle-php-fpm-idle-processes
    INFO: /usr/sbin/crad-webhosting-mgr.pyc: start_recycle_php_fpm_idle_processes, started monitor (pid file /var/run/crad-webhosting-mgr-recycle-php-fpm-idle-processes.pid):1912136

    Esto lanzará el proceso de monitorización, desplegando un proceso permanente auto-supervisado y que queda disponible incluso tras reinicios.

    Antes de arrancar, se comprueba si hay algún pool php-fpm en marcha con un modo distinto de ondemand. Si no lo hay, el monitor no se arranca y se indica así:

    # ARRANQUE SIN POOLS QUE RECICLAR:
    >> crad-webhosting-mgr.pyc --start-recycle-php-fpm-idle-processes
    INFO: /usr/sbin/crad-webhosting-mgr.pyc: start_recycle_php_fpm_idle_processes, not starting monitor: no running php-fpm pool other than pm = ondemand (nothing to recycle)

    Es el resultado esperado en una máquina donde todos los pools los ha creado Core-Admin. El cron de supervisión (ver apartado 3) queda instalado igualmente, de modo que si más adelante arranca un pool con otro modo, el monitor se pondrá en marcha solo en la siguiente pasada del cron (como mucho 5 minutos).

  2. Parada: Para detener el monitor y por tanto la protección proporcionada, simplemente ejecutar:

    # PARADA:
    >> crad-webhosting-mgr.pyc --stop-recycle-php-fpm-idle-processes

    La parada también retira el cron de supervisión.

3. Actualización y mantenimiento

  1. Desactivado permanente: Para máquinas donde se desee que nunca se active este proceso, se puede ejecutar lo siguiente para marcar la instalación:

    # DESACTIVADO PERMANENTE:
    >> crad-webhosting-mgr.pyc --disable-recycle-php-fpm-idle-processes

    Esto no solo desactivará el servicio, también detendrá el monitor arrancado si lo hubiese. Para volver a permitirlo se usa crad-webhosting-mgr.pyc --enable-recycle-php-fpm-idle-processes y, a continuación, el arranque normal.

  2. Recarga tras actualización: durante la actualización de core-admin, si hubiese un monitor arrancado, este será recargado utilizando:

    # RECARGA TRAS ACTUALIZACIÓN:
    >> crad-webhosting-mgr.pyc --reload-recycle-php-fpm-idle-processes

    NOTA: este proceso es automático. No hace falta ejecutarlo manualmente tras actualizar.

    La recarga detiene el monitor y vuelve a lanzar el arranque, que aplica la comprobación descrita en el apartado 2. Por tanto, en las máquinas donde todos los pools son ondemand, tras actualizar el monitor deja de estar en marcha. Es el comportamiento esperado.

  3. Revisión y reactivación en caso de reinicio o fallo: una vez activado el monitor, el sistema instala un cron para auto-supervisar el servicio para asegurar que ejecuta e implementa las tareas de reciclado. El cron está localizado en:

    >> cat /etc/cron.d/crad-webhosting-mgr-recycle-php-fpm-idle-processes-cron
    # Core-Admin : Cron to ensure RecyclePhpFpmIdleProcesses work
    # Enabled on: Mon Apr 14 17:11:52 2025
    # Disable this cron with: /usr/sbin/crad-webhosting-mgr.pyc --stop-recycle-php-fpm-idle-processes
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    */5 * * * * root /usr/sbin/crad-webhosting-mgr.pyc --start-recycle-php-fpm-idle-processes > /dev/null 2>&1

    Cuando no hay pools que reciclar, la ejecución del cron se limita a esa comprobación y termina sin dejar ningún proceso en marcha.

4. Detalles técnicos

4.1. Qué procesos se reciclan

En cada pasada (cada pocos segundos), el monitor revisa los procesos php-fpm: pool <nombre> y, para cada uno:

  1. Descarta los que llevan menos de 60 segundos en marcha.
  2. Descarta los que pertenecen a un pool pm = ondemand (el modo se lee del fichero de configuración del pool).
  3. Observa el proceso durante 1 segundo con strace. Si está esperando una petición (accept(), lo considera idle.
  4. Le envía SIGQUIT, que en php-fpm es la parada ordenada de un proceso: deja de aceptar peticiones nuevas, termina la que tenga en curso, si la hay, y sale. El proceso maestro lo registra como una salida normal (NOTICE: ... exited with code 0), no como un aviso.

4.2. Por qué ya no se actúa sobre pools ondemand

Al analizar en octubre de 2026 errores 503 intermitentes en una tienda online con tráfico continuo se comprobó lo siguiente:

  • En un pool ondemand, un proceso que sigue vivo después de 60 segundos no está parado: si hubiera pasado 30 segundos sin peticiones, php-fpm ya lo habría cerrado. Con varias peticiones por minuto, el sistema reparte las peticiones entre los procesos y ninguno llega a estar 30 segundos inactivo.

  • strace lo encontraba en accept() entre dos peticiones, y el reciclador lo cerraba en pleno uso. En esa tienda eran unos 7 procesos por minuto y más de 3.000 al día, cada uno sustituido inmediatamente por uno nuevo.

  • La señal usada entonces (SIGTERM) termina el proceso en el acto. Si en el instante entre la observación y la señal le había llegado una petición, el visitante recibía un 503, y en el error.log del alojamiento quedaba:

    AH01067: Failed to read FastCGI header
(104)Connection reset by peer: AH01075: Error dispatching request to :

    coincidiendo al segundo con un exited on signal 15 (SIGTERM) en el log de php-fpm.

  • Además, strace se engancha al proceso y lo detiene mientras dura la observación, lo que añadía pequeñas pausas a procesos que estaban trabajando con normalidad.

Por eso el reciclador se limita ahora a los pools en los que php-fpm no cierra los procesos ociosos por sí mismo, y usa siempre la parada ordenada.

4.3. Comprobaciones útiles

Pools que no son ondemand (los únicos sobre los que actuará el reciclador):

grep -L 'pm = ondemand' /etc/core-admin/php/*/php-fpm.d/*.conf

Si el monitor está en marcha:

cat /var/run/crad-webhosting-mgr-recycle-php-fpm-idle-processes.pid && ps -fp $(cat /var/run/crad-webhosting-mgr-recycle-php-fpm-idle-processes.pid)

Procesos cerrados de forma abrupta (no debería aparecer ninguno causado por el reciclador tras la actualización):

grep -h 'exited on signal 15' /var/log/core-admin-php-fpm-*.log | grep -o 'pool [^]]*' | sort | uniq -c | sort -rn | head -20

Peticiones cortadas en un alojamiento:

grep -c 'AH01067' /var/webs/<alojamiento>/logs/error.log

Para ver qué haría el reciclador en una pasada, con detalle de cada proceso:

crad-webhosting-mgr.pyc --recycle-php-fpm-idle-processes -v

Ojo: este comando sí recicla los procesos que considere idle en pools que no sean ondemand. Los de pools ondemand aparecen como skipping process from ondemand pool ....

5. Preguntas frecuentes

¿Tengo que hacer algo tras la actualización?
No. La recarga automática aplica el nuevo comportamiento. Si todos los pools son ondemand, el monitor deja de estar en marcha; si hay pools con otro modo, sigue funcionando sobre ellos.

¿Pierdo la protección frente al consumo de memoria?
No en los pools ondemand: php-fpm cierra sus procesos a los 30 segundos sin peticiones, antes de los 60 que esperaba el reciclador. Un proceso que pasa de ese tiempo está atendiendo tráfico, y reciclarlo solo obliga a crear otro igual.

He detenido el monitor con --stop-recycle-php-fpm-idle-processes. ¿Se volverá a arrancar solo?
No. La parada retira el cron. Para volver a dejarlo supervisado basta con el arranque normal (--start-recycle-php-fpm-idle-processes), que reinstala el cron aunque decida no arrancar el monitor.

Tengo un pool con pm = dynamic (por ejemplo, el pool www de la distribución). ¿Qué pasa con él?
El monitor arranca y recicla sus procesos idle de más de 60 segundos, siempre con parada ordenada.

¿Aparecen 503 por otras causas?
Sí, un reinicio de php-fpm también corta las peticiones en curso (Terminating ... en el log de php-fpm). Conviene cruzar la hora de cada 503 del access.log con el log de php-fpm y el error.log del alojamiento para distinguir el origen.