PHP Detached Mode is a big feature available in LSWS 5.3 and later. OpenLiteSpeed supports PHP detached mode starting from 1.5.6.
In previous versions (LSWS 5.2.x and below), all PHP processes were attached to LiteSpeed Web Server processes. As such, when LiteSpeed Web Server restarted, so would the PHP processes. In PHP Detached Mode, the PHP processes will continue running independently, even when LiteSpeed Web Server restarts.
When you run in PHP ProcessGroup Mode, PHP process groups are still started by the litespeed
process. When the first request for a specific PHP process group comes in, if PHP is not running it, it will be started by LiteSpeed. pstree
will show that PHP process is child of the litespeed
process. That's normal. What's new is that, as of 5.3, once the litespeed
process exits, the PHP process won't quit. It will become independent.
PHP Detached Mode provides an advantage, especially when hundreds of accounts are hosted on the same shared hosting server, with new accounts being rapidly added to it. In cases like this, there is no need to restart all PHP processes during the web server restart. Also, when a user is heavily relying on opcode to reduce the server load, PHP Detached Mode avoids an opcode cache reset during the server restart.
If you are using a control panel, LSWS 5.3 will enable PHP detached mode automatically.
If you are using LSWS 5.3 (native), and explicitly configured an external application for each virtual host, you will need to set Run on Startup to PHP Detached Mode
.
In the past, if there were any php.ini
changes, you would probably want to restart LSWS to apply the changes(since LSWS will restart PHP processes).
As of LSWS 5.3, PHP runs in detached mode and won't be restarted during LSWS restart. If you want to make php.ini
changes effective immediately, there are a few ways to restart PHP processes.
To restart detached PHP processes for the account (vhost) level, you can touch a .lsphp_restart.txt
file under the user's home directory, for example /home/USER1/
on a cPanel/WHM server:
touch /home/USER1/.lsphp_restart.txt
Once .lsphp_restart.txt
is created, the user's PHP will be restarted when next request comes in. The file .lsphp_restart.txt
won't be removed. LSWS will check the timestamp of the file to decide if the user's detached PHP needs to be restarted or not. You can manually remove it if you want to but it's not necessary. Every time you want to restart that user's detached PHP, you can just touch the file again, whether it already exists or not, in order to refresh the timestamp.
To maintain CloudLinux mod_lsapi CRIU feature compatibility, the server will restart PHP if it finds a mod_lsapi_reset_me
file as well.
touch <user_home_dir>/mod_lsapi_reset_me
The user may also restart detached PHP processes from the Advanced page of the LiteSpeed Web Cache Manager cPanel plugin, accessible from within the cPanel dashboard.
To restart detached PHP processes for the server level, you can touch a .lsphp_restart.txt
file under the <lsws_server_root>/admin/tmp/
directory. Usually, that is /usr/local/lsws/admin/tmp/
.
touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt
This can also be accomplished from the 'Actions' page of the LiteSpeed WebAdmin Console or by using the 'Restart Detached PHP Processes' button in the LiteSpeed cPanel/WHM plugin.
All running detached PHP processes will be restarted, but not immediately. Instead, they will restart as soon as the server needs to use that PHP handler.
To stop all lsphp processes immediately, you can manually kill them from the command line:
killall lsphp
PHP Detached Mode doesn't mean that PHP will run forever. It will still follow the Max Idle Time setting. If you want to make PHP live longer, just increase Max Idle Time. Never set it to -1
to indicate “unlimited” since, in process group mode, values under 30
will be automatically converted to the default of 30 seconds. If you want PHP to be running longer, try to enter a large number, such as 3600
.
Changes to Detached Mode will be effective when the app restarts.
Remember, the Detached Mode app isn't started when the server starts up. It only starts when there is traffic hitting the external app. It will be started on demand, and remain running even if LSWS restarts.
The same for the restart. Only if an external application is about to serve a request, will it be checked and restarted if needed.
In previous versions of LSWS (5.2.x and earlier), external apps and PHP handlers are set up via the External App and Script Hander sections, respectively.
On LSWS v5.3 and above, these configurations are no longer required. External apps and script handlers will be autoconfigured by the web server. If you upgrade to v5.3 from an earlier version, the external apps settings will be carried over. (However, you could delete all PHP external apps and PHP handlers and LSWS would still work fine.)
If you install a new fresh LSWS 5.3 installation, you probably won't see any PHP external apps or PHP handlers defined there. Don't worry. This is normal. If you still want to define external apps manually, you can do so. LSWS will honor these settings, and they will override the built-in external apps definition.
Currently, LSWS auto-detects apps and handlers up to PHP 7.4. Two handlers: application/x-httpd-ea-php71
and application/x-httpd-alt-php71
now point to separate handlers, where prior to 5.3, both pointed to the lsphp71 handler configuration.
So, how do you configure PHP settings if there are no external apps defined there anymore? See the new PHP tab in the Web Admin console to adjust the configuration.
Configurations set under the PHP tab or in the <phpConfig>
section, serve as the default for auto-detected PHP handlers, so the memory limit set there will apply to all detected PHP handlers. An explicitly configured PHP handler will still use its own configuration.
On a WHM/cPanel and CloudLinux environment, ea-phpxx
is the default handler pointing to the Easy Apache PHP binary, and alt-phpxx
is the default handler pointing to the CloudLinux PHP selector binary. If you have any need to override the default handler binary, for example, to direct ea-php72
to /opt/alt/php72/usr/bin/lsphp
, you can create or modify an internal app.