Como Reiniciar o PHP-FPM: Todos os Métodos Explicados para Administradores Linux

PHP-FPM (PHP FastCGI Process Manager) é um gestor de processos de alto desempenho que trata a execução do PHP como um serviço separado, desacoplado do servidor web. Reiniciar o PHP-FPM aplica alterações de configuração do `php.ini` ou `php-fpm.conf`, recupera memória com fugas em pools de workers de longa duração e recupera de processos filho sem resposta — tudo sem tocar no Nginx, Apache ou qualquer outro componente da sua stack.

Este guia abrange todos os métodos práticos de reinicialização disponíveis em distribuições Linux modernas e antigas, incluindo controlo baseado em sinais, ambientes com múltiplas versões e estratégias de recarregamento gracioso para implementações em produção sem tempo de inatividade.

Por Que Precisa de Reiniciar o PHP-FPM

Compreender o motivo exato de uma reinicialização evita tempo de inatividade desnecessário e ajuda a escolher o método menos disruptivo:

• Alterações de configuração: Modificações em `php.ini`, `php-fpm.conf` ou qualquer ficheiro de configuração de pool em `/etc/php/<version>/fpm/pool.d/` requerem uma reinicialização ou recarregamento para entrar em vigor. O PHP-FPM lê estes ficheiros apenas na inicialização ou com um sinal `USR2`.
• Recuperação de memória: Os processos worker do PHP-FPM acumulam memória ao longo do tempo, particularmente em servidores de alto tráfego que executam aplicações com uso intensivo de memória. Uma reinicialização controlada recicla os workers e repõe o seu consumo de memória.
• Workers sem resposta: Se os processos filho entrarem num estado zombie ou pararem de aceitar ligações, uma reinicialização limpa a tabela de processos e cria um novo pool.
• Rotação de logs: Após o `logrotate` renomear ou comprimir o ficheiro de log ativo, o PHP-FPM ainda mantém um descritor de ficheiro para o inode antigo. Um recarregamento força-o a abrir o novo descritor de ficheiro, garantindo a continuidade dos logs.
• Invalidação do OPcache: Ao implementar novo código de aplicação, reiniciar o PHP-FPM limpa completamente o OPcache, garantindo que os workers executam o bytecode atualizado em vez de versões em cache desatualizadas.
• Alterações de extensões ou módulos: Adicionar ou remover extensões PHP em `php.ini` requer uma reinicialização completa — um recarregamento por si só é insuficiente porque a lista de extensões é avaliada na inicialização do processo.

Pré-requisitos

Antes de executar qualquer comando de reinicialização, confirme o seguinte:

• Tem acesso `root` ou privilégios `sudo` no servidor.
• Conhece o nome exato do serviço PHP-FPM no seu sistema (varia consoante a distribuição e a versão instalada).
• Identificou o caminho do ficheiro PID se planeia usar controlo baseado em sinais (tipicamente `/run/php/php<version>-fpm.pid` no Debian/Ubuntu ou `/run/php-fpm/php-fpm.pid` no RHEL/CentOS).

Para descobrir o nome do serviço PHP-FPM ativo:

“`bash

systemctl list-units –type=service | grep fpm

“`

Para localizar o caminho do ficheiro PID:

“`bash

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

“`

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

`systemctl` é o gestor de serviços autoritativo em todas as distribuições baseadas em systemd, incluindo Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux e Fedora. É a ferramenta correta para a grande maioria dos servidores em produção.

Reinicialização Padrão

“`bash

sudo systemctl restart php8.2-fpm

“`

Substitua `php8.2-fpm` pela versão instalada no seu sistema (ex.: `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). Em sistemas baseados em RHEL, o serviço é tipicamente denominado `php-fpm` sem prefixo de versão.

Recarregamento Sem Reinicialização Completa

Um recarregamento envia um sinal `USR2` internamente, instruindo o processo master a reler a sua configuração e substituir graciosamente os processos worker. Os pedidos em curso são concluídos antes de os workers serem reciclados:

“`bash

sudo systemctl reload php8.2-fpm

“`

Distinção crítica: `reload` não é disruptivo e é preferível para alterações de configuração em produção. `restart` termina todos os workers imediatamente, o que pode interromper ligações ativas sob alta concorrência.

Parar e Iniciar Separadamente

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Use esta abordagem em dois passos quando precisar de confirmar que o serviço está completamente parado antes de o reiniciar — por exemplo, após alterar o caminho do socket `listen` ou modificar significativamente `pm.max_children`.

Verificar o Estado do Serviço

“`bash

sudo systemctl status php8.2-fpm

“`

Uma saída saudável mostra `Active: active (running)` e lista o PID do master. Se o serviço falhou ao iniciar, `systemctl status` exibe as últimas entradas do journal, o que é mais rápido do que procurar manualmente nos ficheiros de log.

Para transmitir logs em tempo real durante uma reinicialização:

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Método 2: Reiniciar o PHP-FPM com o Comando service Legado

O comando `service` é um wrapper de compatibilidade em torno de `systemctl` em sistemas modernos e invoca diretamente scripts SysVinit em distribuições mais antigas (Ubuntu 14.04, CentOS 6, Debian 7). Continua relevante na gestão de servidores que não foram migrados para systemd.

“`bash

sudo service php-fpm restart

“`

Para parar e iniciar independentemente:

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

Em distribuições que ainda usam SysVinit, o script subjacente está localizado em `/etc/init.d/php-fpm`. Pode invocá-lo diretamente se o wrapper `service` não estiver disponível:

“`bash

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

“`

Método 3: Gerir Múltiplas Versões de PHP Simultaneamente

Servidores que executam painéis de controlo como cPanel, Plesk ou configurações multi-tenant personalizadas frequentemente têm várias versões de PHP instaladas em paralelo. Cada versão é executada como um serviço PHP-FPM independente com a sua própria árvore de configuração, socket e ficheiro PID.

Reiniciar uma Versão 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 as Versões PHP-FPM de Uma Vez

Quando uma alteração a nível de sistema afeta todas as versões (como uma atualização de biblioteca partilhada), reinicie todas as instâncias com um único loop:

“`bash

for ver in 7.4 8.1 8.2; do

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

done

“`

Identificar Qual Versão Serve um Site Específico

Cada virtual host Nginx ou VirtualHost Apache mapeia para um socket PHP-FPM específico. Verifique a configuração do site para determinar qual versão está ativa 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

“`

Se gerir o seu servidor através de um painel de controlo, VPS com cPanel fornece uma interface gráfica para alternar versões de PHP por domínio sem reinicializações manuais do serviço.

Método 4: Enviar Sinais POSIX Diretamente ao Processo Master

O processo master do PHP-FPM responde a um conjunto definido de sinais POSIX. Este método contorna completamente o sistema init e fornece controlo preciso e de baixo nível — essencial em ambientes containerizados, sistemas init personalizados ou quando `systemctl` não está disponível.

Tabela de Referência de Sinais

Recarregar Configuração (Zero Tempo de Inatividade)

“`bash

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

“`

Isto é funcionalmente equivalente a `systemctl reload` e é a forma mais segura de aplicar alterações de configuração `php-fpm.conf` ou de pool num servidor em produção.

Reabrir Ficheiros de Log Após Rotação

“`bash

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

“`

Execute isto imediatamente após `logrotate` ser executado para evitar que o PHP-FPM continue a escrever no ficheiro de log renomeado.

Encerramento Gracioso

“`bash

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

“`

O processo master para de aceitar novas ligações e aguarda que todos os workers ativos completem os seus pedidos atuais antes de sair. Siga isto com `sudo systemctl start php8.2-fpm` para reiniciar o serviço.

Importante: Verifique sempre o caminho do ficheiro PID antes de usar estes comandos. Um caminho incorreto resulta no envio de um sinal para um processo não relacionado. Confirme com:

“`bash

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

ps aux | grep php-fpm

“`

Método 5: Forçar o Encerramento de Processos PHP-FPM com pkill ou killall

Este é um método de último recurso para situações em que o PHP-FPM ficou completamente sem resposta e nem `systemctl` nem o controlo baseado em sinais produz resultados. Termina todos os processos PHP-FPM incondicionalmente, o que interromperá quaisquer pedidos em curso.

“`bash

sudo pkill -9 php-fpm

“`

Ou usando `killall`:

“`bash

sudo killall -9 php-fpm

“`

Após forçar o encerramento, o serviço não reiniciará automaticamente a menos que seja gerido por um supervisor de processos. Inicie-o explicitamente:

“`bash

sudo systemctl start php8.2-fpm

“`

Quando usar isto: Acumulação de processos zombie, processos filho descontrolados a consumir 100% de CPU, ou situações em que o processo master está ativo mas já não gere o seu pool. Antes de recorrer a `pkill -9`, tente `kill -QUIT` no PID do master primeiro — é muito menos disruptivo.

Método 6: Reiniciar o Servidor Web para Afetar Indiretamente o PHP-FPM

Reiniciar o Nginx ou Apache não reinicia o PHP-FPM. Como o PHP-FPM é executado como um serviço completamente independente que comunica através de um socket Unix ou porta TCP, o reinício do servidor web afeta apenas a camada HTTP. Este é um equívoco comum.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

O único cenário em que um reinício do servidor web é relevante para o PHP-FPM é quando modificou a diretiva `fastcgi_pass` no Nginx ou a regra `ProxyPassMatch` no Apache para apontar para um socket PHP-FPM diferente. Nesse caso, o Nginx deve recarregar a sua configuração para ligar ao novo caminho do socket — mas o próprio PHP-FPM ainda precisa do seu próprio reinício separado.

Para manutenção de stack completa, reinicie ambos os serviços na ordem correta: PHP-FPM primeiro, depois o servidor web.

Comparação: Métodos de Reinicialização do PHP-FPM em Resumo

Configuração de Pool PHP-FPM: O Que Requer Reinicialização vs. Recarregamento

Nem todas as alterações de configuração têm o mesmo peso. Saber quais alterações requerem uma reinicialização completa versus um simples recarregamento reduz o tempo de inatividade desnecessário:

Recarregamento (`USR2` / `systemctl reload`) é suficiente para:

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• Alterações de caminho `slowlog`
• Diretivas `php_admin_value` e `php_flag` dentro de ficheiros de pool
• Alterações de caminho `access.log`

Reinicialização completa necessária para:

• Alterações à diretiva `listen` (caminho do socket ou porta TCP)
• Adicionar ou remover extensões PHP em `php.ini`
• Alterar diretivas `user` ou `group` no pool
• Modificar caminhos `include` em `php-fpm.conf`
• Atualizar o próprio binário PHP (atualizações de versão)

Melhores Práticas para Reinicializações de PHP-FPM em Produção

• Prefira sempre `reload` em vez de `restart` em servidores em produção. Um recarregamento recicla os workers graciosamente, completando os pedidos em curso antes de criar substitutos. Uma reinicialização forçada interrompe todas as ligações ativas imediatamente.
• Valide a configuração antes de recarregar. O PHP-FPM fornece uma verificação de sintaxe integrada que impede o carregamento de uma configuração com erros:

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Verifique os logs antes e depois. Reveja `/var/log/php8.2-fpm.log` (ou o caminho definido no seu `php-fpm.conf`) para entradas `WARNING` ou `ERROR` que indiquem falhas de inicialização do pool.
• Monitorize as métricas do pool de workers após a reinicialização. Use a página de estado do PHP-FPM (ativada via `pm.status_path` na configuração do seu pool) para verificar que o número esperado de workers está ativo e inativo após a reinicialização.
• Automatize com pipelines de implementação. Em fluxos de trabalho CI/CD, acione `systemctl reload php-fpm` como um hook pós-implementação em vez de uma reinicialização completa. Isto garante implementações sem tempo de inatividade em cada push de código.
• Configure `pm.max_requests` para reciclar workers automaticamente. Em vez de agendar reinicializações periódicas para combater fugas de memória, configure `pm.max_requests = 500` (ou um valor apropriado) para reiniciar automaticamente cada worker após servir um número fixo de pedidos.

PHP-FPM em Ambientes VPS e Servidor Dedicado

O método de reinicialização que utiliza também é influenciado pelo seu ambiente de alojamento. Num plano de Alojamento VPS com acesso root completo, todos os métodos descritos neste guia estão disponíveis sem restrições. Tem acesso direto a `systemctl`, ao ficheiro PID e à tabela de processos.

Em Servidores Dedicados, onde controla toda a stack de hardware, pode adicionalmente configurar o PHP-FPM com `pm = ondemand` ou `pm = dynamic` para ajustar com precisão o comportamento de criação de workers, e usar ficheiros drop-in `systemd` para personalizar políticas de reinicialização (ex.: `Restart=on-failure`, `RestartSec=5s`).

Se gerir múltiplos sites de clientes através de uma solução de Painéis de Controlo VPS, as operações de reinicialização do PHP-FPM são frequentemente abstraídas na UI do painel, mas compreender os comandos subjacentes continua a ser essencial para cenários de resolução de problemas onde o próprio painel não responde.

Para aplicações que requerem alta concorrência PHP — como Laravel, WordPress multisite ou lojas WooCommerce — combinar o PHP-FPM com uma configuração de pool devidamente ajustada num Servidor Dedicado elimina a contenção de recursos que os ambientes partilhados introduzem.

Matriz de Decisão Técnica: Escolher o Método de Reinicialização Correto

Use esta matriz para selecionar a abordagem correta com base na sua situação específica:

FAQ

Qual é a diferença entre `systemctl restart` e `systemctl reload` para PHP-FPM?

`restart` termina imediatamente todos os processos master e worker e inicia de novo, interrompendo quaisquer pedidos em curso. `reload` envia um sinal `USR2` ao processo master, que cria novos workers com a configuração atualizada enquanto os workers existentes terminam os seus pedidos atuais antes de sair. Use sempre `reload` em produção.

Como encontro o nome correto do serviço PHP-FPM no meu servidor?

Execute `systemctl list-units –type=service | grep fpm`. Em sistemas Debian/Ubuntu com múltiplas versões do PPA `ondrej/php`, verá entradas como `php7.4-fpm.service` e `php8.2-fpm.service`. No RHEL/CentOS com o repositório Remi, a convenção de nomenclatura é `php74-php-fpm.service`.

Reiniciar o PHP-FPM afeta ligações de base de dados ativas ou sessões de utilizador?

Uma reinicialização forçada (`systemctl restart`) termina todos os processos worker imediatamente, o que fecha quaisquer ligações de base de dados persistentes mantidas por esses workers. As sessões de utilizador armazenadas em ficheiros ou numa base de dados não são afetadas porque persistem independentemente dos workers PHP-FPM. Um recarregamento gracioso (`systemctl reload`) permite que os workers completem os seus pedidos atuais, pelo que as ligações persistentes são fechadas de forma limpa.

Por que o PHP-FPM falha ao iniciar após uma reinicialização?

As causas mais comuns são um erro de sintaxe em `php.ini` ou num ficheiro de configuração de pool, um conflito de porta ou caminho de socket (outro processo já a escutar no endereço `listen` configurado), ou permissões insuficientes no diretório do socket. Execute `php-fpm<ver> -t` para validar a sintaxe da configuração e verifique `journalctl -u php<ver>-fpm` para a mensagem de erro exata.

Posso reiniciar o PHP-FPM sem privilégios root ou sudo?

Não numa instalação Linux padrão. O processo master do PHP-FPM é executado como root (abandona os privilégios para o `user`/`group` configurado para os processos worker), e gerir serviços do sistema requer privilégios elevados. Em ambientes de alojamento partilhado, o fornecedor de alojamento trata as reinicializações do PHP-FPM através do seu painel de controlo. Para controlo total sobre o PHP-FPM, um plano de Alojamento VPS com acesso root é a solução adequada.