How to Restart PHP Workers After a Security Update (Every Setup)

As of 23 October 2026, every official PHP2Shell instruction ends the same way: install the fixed PHP, then restart. PHP's own advisory says to "restart every worker." A PHP worker is a background process that runs your site's PHP code. Workers that started before the update keep running the old, vulnerable code until they are replaced.

The direct answer: restart the service that actually runs PHP, which is not always the web server. Then confirm that the PHP processes started after you installed the update. This page lists the documented restart command for each common setup, with its source, and the documented ways to check the result.

Replace version numbers in the commands (such as 8.3) with the version your site runs. If you are not sure which PHP your site uses, start with our guide on how to check your PHP version.

Why the Restart Is Part of the Patch

A package update replaces files on disk. A running PHP process has already loaded the old code into memory, and it keeps using it. That is why the instructions are so consistent:

• PHP's advisory (21 October 2026): "restart every worker."
• The researchers' php2shell.com site: "restart Apache, PHP-FPM and any long-running PHP workers."
• hosting.com: "restart all PHP workers and services. Without the restart, the fix won't take effect."

The documentation for dnf's needs-restarting tool puts it plainly: "processes often need to be restarted to reflect security updates." If you run several PHP versions side by side, update and restart each one that serves a website. CloudLinux makes the same point for hosting servers.

First, Find Out What Runs PHP

The thing to restart depends on how PHP is connected to your web server. A temporary phpinfo() page shows this on its Server API line. Delete the page right after.

PHP-FPM

PHP-FPM (FastCGI Process Manager) is the most common setup behind nginx and modern Apache. The service name depends on the distribution.

Ubuntu and Debian

Debian's packaging names the service php followed by the version and -fpm, so PHP 8.3 is php8.3-fpm:

sudo systemctl restart php8.3-fpm (replace 8.3 with your version)

AlmaLinux, Rocky, RHEL and Fedora

Fedora's service file and AlmaLinux's PHP2Shell post both use the name php-fpm:

sudo systemctl restart php-fpm

Restart or reload?

The official FPM man page says the reload signal (SIGUSR2) does a "graceful reload of all workers + reload of fpm conf/binary," and the upstream, Debian and Fedora service files all map systemctl reload to that signal. Every vendor's PHP2Shell guidance still says restart, and so do we. A restart is the conservative choice for a security fix. Our PHP-FPM and PHP2Shell guide covers pool settings and FPM-specific exposure.

Apache With mod_php

With mod_php, PHP is loaded inside Apache, so Apache is what you restart. On Ubuntu and Debian the service is apache2; on the RHEL family it is httpd:

sudo systemctl restart apache2 (Ubuntu documents sudo systemctl restart apache2.service)
sudo systemctl restart httpd (AlmaLinux 8, RHEL and similar)

Use a full restart, not a graceful one. Apache's documentation explains that a graceful restart replaces child processes, but it does not say whether that loads an updated PHP module. Every vendor instruction we found uses a full restart for mod_php. PHP calls mod_php the highest-risk setup for PHP2Shell; see our Apache mod_php guide.

LiteSpeed and OpenLiteSpeed (lsphp)

This is the setup where a restart is most often missed. LiteSpeed's documentation says: "As of LiteSpeed Web Server version 5.3, PHP runs in Detached mode and will not be restarted when LSWS restarts."

LiteSpeed documents three ways to restart PHP itself:

• Immediately, server-wide: pkill lsphp. In LiteSpeed's words, "All PHP workers will be immediately stopped and a new set of workers will restart right away."
• Gradually, server-wide: sudo touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt. Processes restart "one by one, as soon as the server needs to use each PHP handler."
• One account: touch /path/to/user/home/dir/.lsphp_restart.txt, or the Restart Detached PHP Processes button in LiteSpeed's control panel plugins or the WebAdmin Actions page.

For OpenLiteSpeed, its documentation gives two commands together:

sudo touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt
sudo systemctl restart lsws

Source: LiteSpeed's PHP documentation. Package names and fixed lsphp builds are in our LiteSpeed and PHP2Shell guide.

FrankenPHP

FrankenPHP has PHP built into its binary and Docker images. Because PHP is compiled in, a worker restart or a configuration reload keeps using the binary that is already running. You need FrankenPHP 1.13.2 or later (or a rebuilt image), then a restart of the process.

• deb or rpm packages: FrankenPHP's documentation names the systemd service frankenphp, so: sudo systemctl restart frankenphp
• Docker: pull or rebuild the image, then replace the container (next section).
• Homebrew: the service is dunglas/frankenphp/frankenphp under brew services.

The details, including worker mode, are in our FrankenPHP and PHP2Shell guide.

Docker, Compose and Kubernetes

A container carries its own PHP. Updating the host server does not update it, and pulling a new image does not change containers that are already running. Docker's documentation says docker compose pull "does not start containers based on those images."

The documented sequence for Docker Compose, if you use published images:

docker compose pull
docker compose up -d

If you build your own image, rebuild it from a fixed base image first. Docker documents --pull ("Always attempt to pull a newer version of the image") and --no-cache for docker compose build:

docker compose build --pull
docker compose up -d

According to Docker's compose up reference, when "the service's configuration or image was changed after the container's creation, docker compose up picks up the changes by stopping and recreating the containers." The --force-recreate flag recreates them even when nothing changed.

On Kubernetes, change the image to a new, fixed tag or digest and roll it out. Kubernetes documents kubectl rollout restart deployment/<name> for restarts. It also warns that with the IfNotPresent pull policy, "the image is pulled only if it is not already present locally," and advises against the :latest tag in production. So a restart alone may come back on the old image.

Control Panels: cPanel, Plesk and DirectAdmin

cPanel and WHM (including CloudLinux)

cPanel's restartsrv documentation lists apache_php_fpm ("The Apache PHP-FPM service") and httpd. CloudLinux's PHP2Shell post uses:

/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

The full path in cPanel's docs is /usr/local/cpanel/scripts/restartsrv_ followed by the service name. WHM also has a Restart Services interface. For CloudLinux alt-php, CloudLinux says to "restart your PHP services (Apache, PHP-FPM, or LiteSpeed)."

Plesk

Plesk's knowledge base article "How to restart PHP service in Plesk?" gives two routes. In the panel, go to Tools & Settings > Services Management and restart the PHP service. Over SSH, list the FPM handlers, then restart each one:

plesk bin php_handler --list | grep -E plesk.*fpm | awk -F" " '{ print $1 }'
service plesk-php83-fpm restart (use the names the first command prints)

DirectAdmin

A DirectAdmin staff post on 21 October gave the update commands as da update and da build php, and noted that "PHP upgrade needs to be triggered manually (unless CB cron feature is enabled)." DirectAdmin's PHP-FPM documentation restarts a version like this:

systemctl restart php-fpm83 (PHP 8.3 in this example)

Shared and managed hosting

If you cannot log in to the server, your host handles both the update and the restart. Ask them to confirm both. Our shared responsibility guide explains who owns which part.

How to Confirm the Workers Restarted

Write down the time you installed the update. Then check that the PHP processes started after it.

1. Check the service. systemctl status php8.3-fpm (or apache2, httpd, lsws, frankenphp). The systemd documentation shows the Active line in this form: "active (running) since" followed by the start date and time.
2. Check the processes. The ps manual documents the lstart field as the "time the command started." For example: ps -eo pid,lstart,cmd | grep php-fpm (use apache2, httpd or lsphp instead of php-fpm as needed). Every PHP process should show a start time after your update.
3. Ask the system what still needs a restart. On the RHEL family, sudo dnf needs-restarting -s lists systemd services using files from packages "updated after the given process started." On Debian and Ubuntu, if the needrestart tool is installed, sudo needrestart -r l lists them without restarting anything.
4. Use the FPM status page if you have one. PHP's manual says it reports the "start time" of the pool and of each process. Keep that page restricted to internal requests.
5. For containers, docker compose ps shows each container's status, such as "Up 2 minutes." A container that has been up for days was not replaced.

Then confirm the fixed build is the one running

A fresh start time proves a restart, not a fix. Confirm the build too:

• Package changelog. Debian's security FAQ says to "check the package changelog with apt-get changelog package-name and search for the entry announcing the fix." CloudLinux documents rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)' for its builds.
• Build date. For backported builds that keep the old version number, GoDaddy and Hostinger say a build date of 21 October 2026 or later means the fix is in. php -v shows it after "built:", but the command-line PHP can differ from the one serving your site. A temporary phpinfo() page shows the web server's own build date.
• Version number. Upstream builds should read 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Our fixed versions table lists the distribution package numbers.

Common Mistakes

• Reloading nginx and stopping there. Nginx passes requests to PHP-FPM; it does not run PHP.
• Restarting LiteSpeed but not lsphp. Detached PHP survives a web server restart.
• Restarting one PHP version. Servers with several versions need each one restarted.
• Pulling an image without recreating the container. The old container keeps running the old PHP.
• Trusting php -v alone. It reports the command-line PHP, which may not be the one serving pages.

Conclusion

The PHP2Shell fix is two steps, and the restart is the one people skip. Find what runs PHP on your server, restart that service with the documented command above, confirm every PHP process started after the update, then confirm the build itself. Put the restart into your normal patching routine, as our security patching guide recommends, so it happens every time. If you would rather have a team patch, restart and verify your servers, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions