PHP Site AuditPHP runtime operations
How do LiteSpeed and FrankenPHP operators restart PHP workers safely?
Do not assume every PHP deployment is PHP-FPM. LiteSpeed can serve PHP through its LSAPI modes, including detached processes that may outlive a web-server restart; FrankenPHP can run request handlers in persistent worker mode. Identify the exact handler and deployment model, install the vendor-supported PHP fix, and follow that platform’s documented restart or reload method so old processes no longer serve requests.
Identify the web-facing SAPI
The package name or a shell’s php -v output does not identify what is executing web requests. A site may use PHP-FPM, mod_php, CGI, LiteSpeed’s LSAPI implementation, or an application server such as FrankenPHP. Also distinguish CLI jobs from the web-serving SAPI. Record the virtual host, pool or container, runtime build, and process manager before planning a restart; otherwise an operator can restart the wrong service while stale workers remain active.
Understand LiteSpeed process modes
LiteSpeed documentation describes ProcessGroup, Daemon, Worker, and Detached modes with different process lifetimes and restart behavior. In detached mode, PHP processes can continue independently when LiteSpeed itself restarts. LiteSpeed provides control-panel actions and documented account- or server-level restart procedures; select the procedure that matches the deployment and scope it to affected accounts where appropriate. Avoid copying a terminal command from another hosting layout without confirming it applies.
Account for persistent FrankenPHP workers
FrankenPHP worker mode keeps the application bootstrapped between requests. Its documentation explains that worker processes retain in-memory state, and documents a watch option for development reloads when selected files change. A code change or PHP package replacement should therefore be followed by the service’s normal worker replacement or container rollout, not assumed to take effect because the files or package on disk changed.
Use the vendor-supported lifecycle for this model
Inventory the process supervisor, container/image, worker entrypoint, health checks and rollout strategy. Use the vendor’s current deployment guidance for the installed FrankenPHP version and the framework integration in use. Do not invent a generic restart command: the correct action depends on whether the application is embedded, managed by a process supervisor, orchestrated as containers, or deployed through a hosting panel. Confirm old process IDs or old image replicas have drained using the platform’s normal operational evidence.
Record restart evidence and uncovered pools
For each affected host or service, record the PHP package or image digest, advisory reference, selected SAPI, process mode, operator-approved reload action and completion time. Confirm that all web-facing nodes and relevant CLI or background workers are in scope. Then request a new process or replica inventory and test representative routes, authenticated flows and background work while watching application logs and service health.
A public request can show that a route responded after the change, but it cannot tell whether an idle detached worker, a second virtual host or another region still uses an old runtime. Likewise, restarting the web server is not automatically proof that PHP workers restarted. Report unresolved pools or replicas as unknown and keep the change open until the owner can account for them.
If the setup is managed by cPanel, CloudLinux, a container platform or a hosting vendor, establish which layer owns the PHP selection and restart action before touching server-wide controls. A host-wide restart can affect unrelated sites, while an account-level action may miss a separately configured vhost. Ask for the operator to state the intended scope and confirm each included workload.
Common questions
Will restarting LiteSpeed always restart PHP workers?
Not necessarily. Detached LSAPI processes can outlive a web-server restart; verify the configured mode and follow LiteSpeed’s documented process control.
Can I use FrankenPHP’s watch flag as a production patch process?
The documented watch option is for reloading workers when selected files change; use the deployment method supported by your production supervisor or platform.
What proves old workers are gone?
Use the process or replica inventory for the actual handler and confirm it matches the deployed package or image; a successful public request is not enough.