Troubleshooting¶

Session Locking¶

Symptom: A long-running PHP job eventually makes the server unresponsive and requires a killall lsphp to get back to normal

Potential Cause: The PHP job is locking the PHP session file. Other PHP requests cannot be processed, as they are waiting for the locked session file.

Solution: This issue needs to be addressed within the PHP code itself. If your PHP script is going to be long running, it should create it's own PHP session, or release the session as soon as possible. Long-running PHP scripts should not share PHP sessions with other requests.

If you want more information, here are the steps we have used to diagnose this type of issue.

Run the following command while your long-running PHP script is active, and another request is waiting:

ps -ef | grep php

Make note of the process ID for the waiting request and use it to run the following command (substitute the actual PID for 123456):

strace -tt -T -p 123465

If you see something like this in the output, it indicates that the waiting request is being locked by FD:7:

19:57:13.617826 flock(7, LOCK_EX^Cstrace: Process 123456 detached

Run this command to see what FD:7 is:

lsof -p 123456

You should see output that includes a line like this:

lsphp   414632 nobody    7u   REG                8,5        0  150633 /tmp/sess_4g9st6gmrvvddj15hn7t0b4csl

It indicates that FD:7 is the PHP session file.

If you run the lsof command for the long-running PHP script, you should see the PHP session file, locked at FD:7 in that output as well.

PHP running as web server user¶

In short, if the LiteSpeed binary is owned by the wrong user, it can cause PHP errors. You can restore the correct permissions, with the lsup script, like so:

/usr/local/lsws/admin/misc/lsup.sh -f

The -f forces an update, and during the process, all necessary files will be re-deployed with the correct ownership and permissions, enabling PHP to run correctly.

Why this works¶

In a typical server environment, like with cPanel, Plesk, or DirectAdmin, the web server usually runs as a generic user like apache, nobody, or www-data. For security reasons, PHP is configured to run under the individual site user account.

When you create a new site in your control panel, the system will create a new user for this site, and all files for the site are owned by this user. The Linux file system gives each site its own secure directory, so that each site cannot access files that belong to other sites.

As such, for PHP scripts to read or write files within the site, the PHP process must run as the site’s user. This will give the PHP process the permissions to manipulate files if needed.

But in some unusual situations, or due to mis-configuration, the PHP process might run as nobody, apache, or www-data instead of the intended site's user. When this happens, the PHP process will not be able to manipulate files properly.

One possible reason this might occur is that the setuid attribute of the LiteSpeed binary has been changed. For example, try running this command:

ls -l "$(readlink -f /usr/local/lsws/bin/lscgid)"

It will provide output like this:

-r-sr-xr-x 1 root root 246808 Apr 12 01:48 /usr/local/lsws/bin/lscgid.6.3.2

In this case, it shows the r-s permission, indicating the setuid bit is correctly set and the file is owned by root.

However, the output may show something else, like this:

-r-xr-xr-x 1 nobody nobody 246728 Apr  4 10:40 /usr/local/lsws/bin/lscgid.6.3.2

Here you can see that the file ownership and permissions are incorrect. The file is owned by nobody instead of root and the setuid bit is set to r-x.

Run the lsup script to set the permissions back to normal and allow PHP to run correctly.