# Após a atualização: reiniciar o PHP-FPM e todos os workers > Reiniciar o PHP-FPM após a atualização do PHP2Shell: porque ficheiros novos não bastam, que serviços contam e como verificar que nenhum worker antigo corre. Fonte: https://phpsos.de/pt/php2shell/php-fpm-neustart/ Atualizado em: 25/10/2026 Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6 **Em resumo:** depois da atualização do PHP, tem de reiniciar o PHP-FPM e todos os outros serviços que carregam o PHP. Ficheiros novos no disco não bastam enquanto processos PHP antigos correrem na memória. Só depois do reinício o servidor trabalha com o código corrigido do PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou com o backport do seu fornecedor. ## Porque tem de reiniciar o PHP-FPM Uma atualização de pacotes substitui os ficheiros no disco. Os processos que já estão em execução, no entanto, já carregaram o código do programa antigo para a memória e continuam a trabalhar com ele. O PHP-FPM, o Apache com mod_php ou o LiteSpeed mantêm muitas vezes os seus workers vivos durante dias. Para o PHP2Shell, isto é particularmente importante. A vulnerabilidade [CVE-2026-109619](https://phpsos.de/pt/php2shell/cve-2026-109619/) depende precisamente de estado que persiste entre pedidos no mesmo worker. Um worker com código antigo continua vulnerável, seja qual for a versão que está no disco. Segundo o php.net, por isso, todos os workers e processos devem ser reiniciados. Alguns gestores de pacotes reiniciam os serviços automaticamente na atualização, outros não. Não confie nisso, verifique o resultado. Um quadro típico do dia a dia: a gestão de pacotes comunica “PHP atualizado”, a monitorização não mostra erros, o site funciona. Mesmo assim, os workers antigos continuam a atender cada pedido, porque ninguém reiniciou o serviço. De fora, este estado não se reconhece. Por isso, a verificação das horas de arranque dos processos faz parte de cada atualização. ## Que serviços carregam o PHP? | Modo de operação | O que reiniciar | Comando típico (os nomes variam conforme a distribuição) | |---|---|---| | PHP-FPM | cada serviço FPM, por versão instalada | `systemctl restart php8.3-fpm` ou `systemctl restart php-fpm` | | Apache com mod_php | Apache | `systemctl restart apache2` ou `systemctl restart httpd` | | php-cgi | o servidor web que o chama ou o wrapper FastCGI | conforme a configuração | | LiteSpeed | LiteSpeed e os processos lsphp | através da gestão do LiteSpeed ou do respetivo serviço | | FrankenPHP | o serviço FrankenPHP ou o contentor | `systemctl restart frankenphp` ou recriar o contentor | | Docker, Kubernetes | recriar os contentores a partir de uma nova imagem | ver [Aplicar patches ao PHP em contentores Docker](https://phpsos.de/pt/php2shell/docker-container-patchen/) | No mod_php aplica-se: a atualização afeta o próprio Apache, porque o PHP está em cada processo do Apache. Porque este modo de operação é particularmente delicado, vê-se em [Porque é que o mod_php tem o risco mais elevado](https://phpsos.de/pt/php2shell/mod-php-risiko/). Para o LiteSpeed, encontra pormenores na página [LiteSpeed e LSAPI](https://phpsos.de/pt/server/litespeed/). ## Reiniciar o PHP-FPM: os comandos Primeiro, encontre todos os serviços PHP no servidor. O Plesk, o cPanel e outras interfaces trazem serviços PHP próprios, com nomes próprios; a lista mostra-os também. ```bash systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd" ``` Depois, reinicie cada serviço PHP encontrado, e não apenas o primeiro: ```bash sudo systemctl restart php8.3-fpm sudo systemctl restart php8.2-fpm # se estiver instalado um segundo ramo sudo systemctl restart apache2 # com mod_php; família RHEL: httpd ``` Recomendamos `restart` em vez de `reload`. No reload, o processo principal mantém-se; isso destina-se a alterações de configuração. Depois de uma atualização de segurança, quer ter a certeza de que todos os processos são novos. > **Importante:** > Se definiu adicionalmente medidas provisórias como `session.upload_progress.enabled=0` ou limites de memória fixos, também estas só produzem efeito depois do reinício. Um reinício resolve ambas as coisas num só passo. ## Verificar que já não corre nenhum worker antigo Compare a hora de arranque dos processos com o momento da atualização. Todos os comandos são apenas de leitura. ```bash ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm systemctl status php8.3-fpm # linha “Active: … since …” needrestart -r l # Debian/Ubuntu, se instalado ``` Se um processo for mais antigo do que a atualização, não foi abrangido. Causas frequentes são um segundo ramo do PHP esquecido, um serviço de pool próprio de um painel de alojamento ou um contentor que foi apenas reiniciado em vez de recriado a partir da imagem nova. Se corre a versão certa, mostra-o a página [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/). ## Documentar o reinício Anote, para cada servidor, o momento da atualização e do reinício. Este momento separa o tempo em que o servidor esteve vulnerável do tempo depois. Para uma posterior verificação de vestígios, para as seguradoras e para uma eventual notificação nos termos do RGPD, é o ponto de referência mais importante. Guarde também os registos do servidor desde 20 de outubro, como recomenda a imprensa especializada. Em servidores com muitos sites, vale a pena uma pequena tabela: servidor, serviço, versão do PHP, versão do pacote, momento do reinício e a pessoa que reiniciou. Assim, as lacunas na cobertura detetam-se depressa, por exemplo um pool que foi esquecido ou um sistema de teste que ninguém tinha na lista. ## Como ajuda concretamente a PHP SOS? No âmbito do [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/), assumimos a atualização e o reinício como um processo coerente: - **Identificar os serviços:** encontramos todos os processos que carregam o PHP, também os de painéis de alojamento e contentores. - **Reiniciar de forma controlada,** combinado consigo para um momento adequado e com atenção a encomendas ou formulários em curso. - **Verificar depois** que nenhum processo é mais antigo do que a atualização e que o site responde normalmente. - **Registar:** versões, estados de pacote e momentos de reinício por servidor. ## Perguntas frequentes **Basta systemctl reload em vez de restart?** Para o PHP2Shell, recomendamos restart. Um reload costuma reiniciar os workers, mas o processo principal pode continuar a correr. Com restart, garante que não sobra nenhum processo com código antigo. À breve interrupção contrapõe-se um comprovativo claro. **Tenho de reiniciar o servidor inteiro depois da atualização do PHP?** Em regra, não. Basta reiniciar todos os serviços que carregam o PHP: PHP-FPM, Apache no caso do mod_php, LiteSpeed, FrankenPHP ou os contentores afetados. Reiniciar o servidor inteiro é a variante simples quando não tem a certeza de que serviços usam o PHP. **O meu fornecedor de alojamento reinicia o PHP automaticamente após a atualização?** Depende do fornecedor. Pergunte concretamente se, depois do patch, todos os processos PHP foram reiniciados e peça que lho confirmem por escrito. ## Fontes - [php.net: avisos de segurança](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)