Cómo reiniciar PHP-FPM: todos los métodos explicados para administradores de Linux

PHP-FPM (PHP FastCGI Process Manager) es un gestor de procesos de alto rendimiento que maneja la ejecución de PHP como un servicio independiente, desacoplado del servidor web. Reiniciar PHP-FPM aplica los cambios de configuración de `php.ini` o `php-fpm.conf`, recupera memoria con fugas en grupos de trabajadores de larga ejecución y se recupera de procesos hijo que no responden, todo sin tocar Nginx, Apache ni ningún otro componente de tu stack.

Esta guía cubre todos los métodos prácticos de reinicio disponibles en distribuciones Linux modernas y heredadas, incluyendo control basado en señales, entornos con múltiples versiones y estrategias de recarga sin interrupciones para implementaciones en producción con tiempo de inactividad cero.

Por qué necesitas reiniciar PHP-FPM

Comprender el desencadenante exacto de un reinicio evita tiempos de inactividad innecesarios y te ayuda a elegir el método menos disruptivo:

• Cambios de configuración: Las modificaciones en `php.ini`, `php-fpm.conf` o cualquier archivo de configuración de grupo bajo `/etc/php/<version>/fpm/pool.d/` requieren un reinicio o recarga para que surtan efecto. PHP-FPM lee estos archivos solo al inicio o ante una señal `USR2`.
• Recuperación de memoria: Los procesos trabajadores de PHP-FPM acumulan memoria con el tiempo, especialmente en servidores de alto tráfico que ejecutan aplicaciones con uso intensivo de memoria. Un reinicio controlado recicla los trabajadores y restablece su huella de memoria.
• Trabajadores que no responden: Si los procesos hijo entran en estado zombie o dejan de aceptar conexiones, un reinicio limpia la tabla de procesos y genera un nuevo grupo.
• Rotación de registros: Después de que `logrotate` renombra o comprime el archivo de registro activo, PHP-FPM todavía mantiene un descriptor de archivo al antiguo inodo. Una recarga lo obliga a abrir el nuevo descriptor de archivo, garantizando la continuidad de los registros.
• Invalidación de OPcache: Al implementar nuevo código de aplicación, reiniciar PHP-FPM vacía completamente el OPcache, garantizando que los trabajadores ejecuten el bytecode actualizado en lugar de versiones en caché obsoletas.
• Cambios de extensiones o módulos: Agregar o eliminar extensiones de PHP en `php.ini` requiere un reinicio completo; una recarga por sí sola es insuficiente porque la lista de extensiones se evalúa durante la inicialización del proceso.

Requisitos previos

Antes de ejecutar cualquier comando de reinicio, confirma lo siguiente:

• Tienes acceso `root` o privilegios `sudo` en el servidor.
• Conoces el nombre exacto del servicio PHP-FPM en tu sistema (varía según la distribución y la versión instalada).
• Has identificado la ruta del archivo PID si planeas usar control basado en señales (normalmente `/run/php/php<version>-fpm.pid` en Debian/Ubuntu o `/run/php-fpm/php-fpm.pid` en RHEL/CentOS).

Para descubrir el nombre del servicio PHP-FPM activo:

“`bash

systemctl list-units –type=service | grep fpm

“`

Para localizar la ruta del archivo PID:

“`bash

grep -i pid /etc/php/*/fpm/php-fpm.conf

“`

Método 1: Reiniciar PHP-FPM con systemctl (Recomendado)

`systemctl` es el gestor de servicios autorizado en todas las distribuciones basadas en systemd, incluyendo Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux y Fedora. Es la herramienta correcta para la gran mayoría de servidores en producción.

Reinicio estándar

“`bash

sudo systemctl restart php8.2-fpm

“`

Reemplaza `php8.2-fpm` con la versión instalada en tu sistema (p. ej., `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). En sistemas basados en RHEL, el servicio normalmente se llama `php-fpm` sin prefijo de versión.

Recarga sin reinicio completo

Una recarga envía una señal `USR2` internamente, instruyendo al proceso maestro a releer su configuración y reemplazar graciosamente los procesos trabajadores. Las solicitudes en vuelo existentes se completan antes de que los trabajadores sean reciclados:

“`bash

sudo systemctl reload php8.2-fpm

“`

Distinción crítica: `reload` no es disruptivo y es preferible para cambios de configuración en producción. `restart` termina todos los trabajadores inmediatamente, lo que puede interrumpir conexiones activas bajo alta concurrencia.

Detener e iniciar por separado

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Usa este enfoque de dos pasos cuando necesites confirmar que el servicio está completamente detenido antes de volver a iniciarlo; por ejemplo, después de cambiar la ruta del socket `listen` o modificar significativamente `pm.max_children`.

Verificar el estado del servicio

“`bash

sudo systemctl status php8.2-fpm

“`

Una salida correcta muestra `Active: active (running)` y lista el PID maestro. Si el servicio no pudo iniciarse, `systemctl status` muestra las últimas entradas del diario, lo que es más rápido que buscar manualmente en los archivos de registro.

Para transmitir registros en vivo durante un reinicio:

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Método 2: Reiniciar PHP-FPM con el comando service heredado

El comando `service` es un envoltorio de compatibilidad alrededor de `systemctl` en sistemas modernos e invoca directamente los scripts SysVinit en distribuciones más antiguas (Ubuntu 14.04, CentOS 6, Debian 7). Sigue siendo relevante al gestionar servidores que no han sido migrados a systemd.

“`bash

sudo service php-fpm restart

“`

Para detener e iniciar de forma independiente:

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

En distribuciones que aún usan SysVinit, el script subyacente se encuentra en `/etc/init.d/php-fpm`. Puedes invocarlo directamente si el envoltorio `service` no está disponible:

“`bash

sudo /etc/init.d/php-fpm restart

“`

Método 3: Gestionar múltiples versiones de PHP simultáneamente

Los servidores que ejecutan paneles de control como cPanel, Plesk o configuraciones personalizadas multi-tenant frecuentemente tienen varias versiones de PHP instaladas en paralelo. Cada versión se ejecuta como un servicio PHP-FPM independiente con su propio árbol de configuración, socket y archivo PID.

Reiniciar una versión específica

“`bash

Debian/Ubuntu (packages from ondrej/php PPA or distribution repos)

sudo systemctl restart php7.4-fpm

sudo systemctl restart php8.1-fpm

sudo systemctl restart php8.2-fpm

RHEL/CentOS with Remi repository

sudo systemctl restart php74-php-fpm

sudo systemctl restart php81-php-fpm

“`

Reiniciar todas las versiones de PHP-FPM a la vez

Cuando un cambio a nivel de sistema afecta a todas las versiones (como una actualización de biblioteca compartida), reinicia todas las instancias con un solo bucle:

“`bash

for ver in 7.4 8.1 8.2; do

sudo systemctl restart php${ver}-fpm && echo "php${ver}-fpm restarted"

done

“`

Identificar qué versión sirve a un sitio específico

Cada host virtual de Nginx o VirtualHost de Apache se mapea a un socket PHP-FPM específico. Verifica la configuración del sitio para determinar qué versión está activa antes de reiniciar:

“`bash

Nginx

grep fastcgi_pass /etc/nginx/sites-enabled/yourdomain.conf

Apache with mod_proxy_fcgi

grep SetHandler /etc/apache2/sites-enabled/yourdomain.conf

“`

Si gestionas tu servidor a través de un panel de control, VPS con cPanel proporciona una interfaz gráfica para cambiar versiones de PHP por dominio sin reinicios manuales del servicio.

Método 4: Enviar señales POSIX directamente al proceso maestro

El proceso maestro de PHP-FPM responde a un conjunto definido de señales POSIX. Este método omite completamente el sistema init y te da un control preciso y de bajo nivel, esencial en entornos contenerizados, sistemas init personalizados o cuando `systemctl` no está disponible.

Tabla de referencia de señales

Recargar configuración (tiempo de inactividad cero)

“`bash

sudo kill -USR2 $(cat /run/php/php8.2-fpm.pid)

“`

Esto es funcionalmente equivalente a `systemctl reload` y es la forma más segura de aplicar cambios de configuración de `php-fpm.conf` o de grupos en un servidor en vivo.

Reabrir archivos de registro después de la rotación

“`bash

sudo kill -USR1 $(cat /run/php/php8.2-fpm.pid)

“`

Ejecuta esto inmediatamente después de que `logrotate` se ejecute para evitar que PHP-FPM continúe escribiendo en el archivo de registro renombrado.

Apagado gracioso

“`bash

sudo kill -QUIT $(cat /run/php/php8.2-fpm.pid)

“`

El proceso maestro deja de aceptar nuevas conexiones y espera a que todos los trabajadores activos completen sus solicitudes actuales antes de salir. Sigue esto con `sudo systemctl start php8.2-fpm` para volver a activar el servicio.

Importante: Siempre verifica la ruta del archivo PID antes de usar estos comandos. Una ruta incorrecta resulta en enviar una señal a un proceso no relacionado. Confirma con:

“`bash

cat /run/php/php8.2-fpm.pid

ps aux | grep php-fpm

“`

Método 5: Forzar la terminación de procesos PHP-FPM con pkill o killall

Este es un método de último recurso para situaciones en las que PHP-FPM se ha vuelto completamente irresponsivo y ni `systemctl` ni el control basado en señales produce resultados. Termina todos los procesos PHP-FPM incondicionalmente, lo que interrumpirá cualquier solicitud en vuelo.

“`bash

sudo pkill -9 php-fpm

“`

O usando `killall`:

“`bash

sudo killall -9 php-fpm

“`

Después de forzar la terminación, el servicio no se reiniciará automáticamente a menos que esté gestionado por un supervisor de procesos. Inícialo explícitamente:

“`bash

sudo systemctl start php8.2-fpm

“`

Cuándo usar esto: Acumulación de procesos zombie, procesos hijo desbocados consumiendo 100% de CPU, o situaciones donde el proceso maestro está vivo pero ya no gestiona su grupo. Antes de recurrir a `pkill -9`, intenta `kill -QUIT` en el PID maestro primero: es mucho menos disruptivo.

Método 6: Reiniciar el servidor web para afectar indirectamente a PHP-FPM

Reiniciar Nginx o Apache no reinicia PHP-FPM. Dado que PHP-FPM se ejecuta como un servicio completamente independiente que se comunica a través de un socket Unix o puerto TCP, el reinicio del servidor web solo afecta la capa HTTP. Este es un malentendido común.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

El único escenario donde un reinicio del servidor web es relevante para PHP-FPM es cuando has modificado la directiva `fastcgi_pass` en Nginx o la regla `ProxyPassMatch` en Apache para apuntar a un socket PHP-FPM diferente. En ese caso, Nginx debe recargar su configuración para conectarse a la nueva ruta del socket, pero PHP-FPM en sí todavía necesita su propio reinicio separado.

Para el mantenimiento completo del stack, reinicia ambos servicios en el orden correcto: PHP-FPM primero, luego el servidor web.

Comparación: Métodos de reinicio de PHP-FPM de un vistazo

Configuración de grupos PHP-FPM: qué requiere reinicio vs. recarga

No todos los cambios de configuración tienen el mismo peso. Saber qué cambios requieren un reinicio completo frente a una simple recarga reduce el tiempo de inactividad innecesario:

La recarga (`USR2` / `systemctl reload`) es suficiente para:

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• Cambios de ruta de `slowlog`
• Directivas `php_admin_value` y `php_flag` dentro de los archivos de grupo
• Cambios de ruta de `access.log`

Se requiere reinicio completo para:

• Cambios en la directiva `listen` (ruta del socket o puerto TCP)
• Agregar o eliminar extensiones PHP en `php.ini`
• Cambiar las directivas `user` o `group` en el grupo
• Modificar las rutas de `include` en `php-fpm.conf`
• Actualizar el binario PHP en sí (actualizaciones de versión)

Mejores prácticas para reinicios de PHP-FPM en producción

• Siempre prefiere `reload` sobre `restart` en servidores en vivo. Una recarga recicla los trabajadores graciosamente, completando las solicitudes en vuelo antes de generar reemplazos. Un reinicio forzado interrumpe todas las conexiones activas inmediatamente.
• Valida la configuración antes de recargar. PHP-FPM proporciona una verificación de sintaxis integrada que evita cargar una configuración incorrecta:

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Revisa los registros antes y después. Revisa `/var/log/php8.2-fpm.log` (o la ruta definida en tu `php-fpm.conf`) para entradas `WARNING` o `ERROR` que indiquen fallos de inicio del grupo.
• Monitorea las métricas del grupo de trabajadores después del reinicio. Usa la página de estado de PHP-FPM (habilitada mediante `pm.status_path` en la configuración de tu grupo) para verificar que el número esperado de trabajadores esté activo e inactivo después del reinicio.
• Automatiza con pipelines de implementación. En flujos de trabajo CI/CD, activa `systemctl reload php-fpm` como un hook post-implementación en lugar de un reinicio completo. Esto garantiza implementaciones sin tiempo de inactividad en cada push de código.
• Configura `pm.max_requests` para reciclar trabajadores automáticamente. En lugar de programar reinicios periódicos para combatir fugas de memoria, configura `pm.max_requests = 500` (o un valor apropiado) para reiniciar automáticamente cada trabajador después de servir un número fijo de solicitudes.

PHP-FPM en entornos VPS y servidores dedicados

El método de reinicio que uses también está influenciado por tu entorno de alojamiento. En un plan de Hosting VPS con acceso root completo, todos los métodos descritos en esta guía están disponibles sin restricciones. Tienes acceso directo a `systemctl`, al archivo PID y a la tabla de procesos.

En Servidores Dedicados, donde controlas todo el stack de hardware, también puedes configurar PHP-FPM con `pm = ondemand` o `pm = dynamic` para ajustar con precisión el comportamiento de generación de trabajadores, y usar archivos drop-in de `systemd` para personalizar las políticas de reinicio (p. ej., `Restart=on-failure`, `RestartSec=5s`).

Si gestionas múltiples sitios de clientes a través de una solución de Paneles de Control VPS, las operaciones de reinicio de PHP-FPM a menudo se abstraen en la interfaz de usuario del panel, pero comprender los comandos subyacentes sigue siendo esencial para escenarios de resolución de problemas donde el propio panel no responde.

Para aplicaciones que requieren alta concurrencia de PHP, como Laravel, WordPress multisite o tiendas WooCommerce, combinar PHP-FPM con una configuración de grupo correctamente ajustada en un Servidor Dedicado elimina la contención de recursos que introducen los entornos compartidos.

Matriz de decisión técnica: elegir el método de reinicio correcto

Usa esta matriz para seleccionar el enfoque correcto según tu situación específica:

Preguntas frecuentes

¿Cuál es la diferencia entre `systemctl restart` y `systemctl reload` para PHP-FPM?

`restart` termina inmediatamente todos los procesos maestros y trabajadores y comienza de nuevo, interrumpiendo cualquier solicitud en vuelo. `reload` envía una señal `USR2` al proceso maestro, que genera nuevos trabajadores con la configuración actualizada mientras los trabajadores existentes terminan sus solicitudes actuales antes de salir. Siempre usa `reload` en producción.

¿Cómo encuentro el nombre correcto del servicio PHP-FPM en mi servidor?

Ejecuta `systemctl list-units –type=service | grep fpm`. En sistemas Debian/Ubuntu con múltiples versiones del PPA `ondrej/php`, verás entradas como `php7.4-fpm.service` y `php8.2-fpm.service`. En RHEL/CentOS con el repositorio Remi, la convención de nomenclatura es `php74-php-fpm.service`.

¿Reiniciar PHP-FPM afecta las conexiones activas a la base de datos o las sesiones de usuario?

Un reinicio forzado (`systemctl restart`) termina todos los procesos trabajadores inmediatamente, lo que cierra cualquier conexión persistente a la base de datos mantenida por esos trabajadores. Las sesiones de usuario almacenadas en archivos o en una base de datos no se ven afectadas porque persisten independientemente de los trabajadores PHP-FPM. Una recarga graciosa (`systemctl reload`) permite a los trabajadores completar sus solicitudes actuales, por lo que las conexiones persistentes se cierran limpiamente.

¿Por qué PHP-FPM falla al iniciar después de un reinicio?

Las causas más comunes son un error de sintaxis en `php.ini` o en un archivo de configuración de grupo, un conflicto de puerto o ruta de socket (otro proceso ya escuchando en la dirección `listen` configurada), o permisos insuficientes en el directorio del socket. Ejecuta `php-fpm<ver> -t` para validar la sintaxis de la configuración y verifica `journalctl -u php<ver>-fpm` para el mensaje de error exacto.

¿Puedo reiniciar PHP-FPM sin privilegios de root o sudo?

No en una instalación estándar de Linux. El proceso maestro de PHP-FPM se ejecuta como root (abandona los privilegios al `user`/`group` configurado para los procesos trabajadores), y gestionar servicios del sistema requiere privilegios elevados. En entornos de alojamiento compartido, el proveedor de alojamiento gestiona los reinicios de PHP-FPM a través de su panel de control. Para control total sobre PHP-FPM, un plan de Hosting VPS con acceso root es la solución adecuada.