Troubleshouting

Navigation:  Apache mod_lsapi >

Troubleshouting

Previous pageReturn to chapter overviewNext page

Debugging mod_lsapi issues: error_log & sulsphp_log

 

mod_lsapi errors will be located in error_log and sulsphp_log.

Note that errors can appear in both logs at the same time, and you might need to refer to both of them to solve the issue.

 

See next table for more details:

 

error_log

sulsphp_log

Solution

Could not connect to lsphp backend: connect to lsphp failed: 111 Connection refused. Increase memory limit for LVE ID

uid: (xxx/xxxxxxxx) gid: (xxx/xxxxxxxxxx) cmd: /usr/local/bin/lsphp

Increase pmem or vmem limits for the user uid.

read from backend socket failed: errno 104. Increase lsapi_backend_children parameter please.

No need to check this log.

Increase value of lsapi_backend_children in lsapi.conf.

 

Error sending request: ReceiveLSHeader: nothing to read from backend socket

No need to check this log.

lsphp was killed. It can be due to apache restart or lfd. If you see this  message too often - change lsapi_terminate_backends_on_exit to Off in lsapi.conf or add to /etc/csf/csf.pignore the following lines: exe:/usr/local/bin/lsphp

pexe:/opt/alt/php.*/usr/bin/lsphp

Error sending request (lsphp is killed?): ReceiveLSHeader: nothing to read from backend socket, referer: http://XXXXXXX

Child process with pid: XXXXX was killed by signal: 11, core dump: 0

No need to check this log.

lsphp has crashed. Next slide will explain what to do (core dump creating). Also, check configuration options for apc and suhosin in php.ini. Once you have a core file generated at DocumentRoot contact helpdesk.cloudlinux.com so we can investigate the cause.

Could not connect to lsphp backend: connect to lsphp failed: 111 Connection refused

 

file is writable by others: (///usr/local/bin/lsphp)

Incorrect lsphp file permissions. For fixing:

chmod 755 /usr/local/bin/lsphp

cagefsctl --force-update.

Could not determine uid/gid for request

No need to check this log.

UID/GID are not set in  virtualhost. Set lsapi_use_default_uid On in lsapi.conf (it is On by default since 0.1-98 version, this solution is for older versions).

Own id for script file (/xxxx/xxx/xxxx) is xxx; should be xxxx

No need to check this log.

File is not owned by the user PHP executed by. To overwrite (insecure), set lsapi_target_perm Off in lsapi.conf.

 

Could not connect to lsphp backend: connect to lsphp failed: 111 Connection refused

Entering jail error

Check if cagefs enabled. Try running cagefsctl --remount-all.

connect_lsphp: connect to lsphp failed: tries XXX exceeded with timeout XXXXX

Could not connect to lsphp backend: connect to lsphp failed: 111 Connection refused

uid: (xxx/xxxxxxxx) gid: (xxx/xxxxxxxxxx) cmd: /usr/local/bin/lsphp

Check if /tmp/lshttpd (global /tmp is not inside CageFS) exists and owner should be apache:apache for DA,Plesk,iWorx,ISPManager and nobody for cPanel.

 

 

Non-standard apache user

 

If apache runs under a username other than "apache" or "nobody", you should rebuild sulsphp (where username is built in for security reasons) with corresponding username:

 

$ yum install liblsapi liblsapi-devel 
$ cd ~
$ wget http://repo.cloudlinux.com/cloudlinux/sources/da/mod_lsapi.tar.gz
$ tar zxvf mod_lsapi.tar.gz
$ cd mod-lsapi-0.1-37
$ cmake -DHTTPD_USER=<new user name> .
$ make
$ make install

 
This will:

-- Install: /usr/lib/apache/mod_lsapi.so (or to another correct httpd modules path)

-- Install: /usr/sbin/sulsphp

 

lsphp started under user apache/nobody

 

Check if SuExecUserGroup specified for virtual hosts. This parameter is used by mod_lsapi for user identification.

 

Could not connect to lsphp backend: connect(/tmp/lshttpd/lsapi_application-x-httpd-lsphp_XXX.sock) failed: 111 Connection refused

 

Switch in lsapi.conf or mod_lsapi.conf value to: lsapi_terminate_backends_on_exit Off

 

Check if empty: cat /etc/cron.d/kill_orphaned_php-cron | grep lsphp, then run:

 

yum install lve-utils

 

Then restart cron service.

 

Running PHP for users with UID < 99

 

If you need to run PHP using mod_lsapi using users with UID < 99, you would need to re-compile sulsphp:

 

$ yum install liblsapi liblsapi-devel

$ cd ~

$ wget http://repo.cloudlinux.com/cloudlinux/sources/da/mod_lsapi.tar.gz

$ tar zxvf mod_lsapi.tar.gz

$ cd mod-lsapi-0.1-XX

$ cmake -DUID_MIN=80 -DGID_MIN=80 .

$ make

$ make install

 

will be installed

-- Installing: /usr/lib/apache/mod_lsapi.so (or another httpd modules path)

-- Installing: /usr/sbin/sulsphp

 

Apache binary called not httpd (httpd.event, httpd.worker)

 

$ yum install liblsapi liblsapi-devel

$ cd ~

$ wget http://repo.cloudlinux.com/cloudlinux/sources/da/mod_lsapi.tar.gz

$ tar zxvf mod_lsapi.tar.gz

$ cd mod-lsapi-0.1-XX

$ cmake -DPARENT_NAME="<apache binary name>".

$ make

$ make install

 

Will be installed:

-- Installing: /usr/lib/apache/mod_lsapi.so (or another httpd modules path)

-- Installing: /usr/sbin/sulsphp

 

6. WHMCS Status page not accessible after installing CL and mod_lsapi (cPanel).

 

add user: useradd userstat

add to file (to the end of file before </IfModule>) /usr/local/apache/conf/conf.d/lsapi.conf: <Directory /usr/local/apache/htdocs/>

lsapi_user_group userstat userstat

</Directory>

service httpd restart

 

This is safe solution for easyapache rebuilding and cpanel-mod-lsapi updating.

 

PHP page with Suhosin return 503 error

 

Make php.ini for suhosin as recommended below:

 

[suhosin]

suhosin.simulation = Off

suhosin.mail.protect = 1

suhosin.cookie.disallow_nul = Off

suhosin.cookie.max_array_depth = 1000

suhosin.cookie.max_array_index_length = 500

suhosin.cookie.max_name_length = 500

suhosin.cookie.max_totalname_length = 500

suhosin.cookie.max_value_length = 200000

suhosin.cookie.max_vars = 16384

suhosin.get.disallow_nul = Off

suhosin.get.max_array_depth = 1000

suhosin.get.max_array_index_length = 500

suhosin.get.max_name_length = 500

suhosin.get.max_totalname_length = 500

suhosin.get.max_value_length = 1000000

suhosin.get.max_vars = 16384

suhosin.post.disallow_nul = Off

suhosin.post.max_array_depth = 1000

suhosin.post.max_array_index_length = 500

suhosin.post.max_name_length = 500

suhosin.post.max_totalname_length = 500

suhosin.post.max_value_length = 1000000

suhosin.post.max_vars = 16384

suhosin.request.disallow_nul = Off

suhosin.request.max_array_depth = 1000

suhosin.request.max_array_index_length = 500

suhosin.request.max_totalname_length = 500

suhosin.request.max_value_length = 1000000

suhosin.request.max_vars = 16384

suhosin.request.max_varname_length = 524288

suhosin.upload.max_uploads = 300

suhosin.upload.disallow_elf = Off

suhosin.session.cryptua = Off

suhosin.session.encrypt = Off

suhosin.session.max_id_length = 1024

suhosin.executor.allow_symlink = Off

suhosin.executor.disable_eval = Off

suhosin.executor.disable_emodifier = Off

suhosin.executor.include.max_traversal = 8

 

 

PHP page with APC return 503 error

 

Make php.ini for APC as recommended below:

 

[apc]

...

apc.shm_segments=1

apc.shm_size=32

...

 

shared memory should be not less than 32MB

 

Messages appearing in error_log: Child process with pid: XXXXX was killed by signal: 11, core dump: 0

 

This means that lsphp was crashed. Solution:

 

Check if apc for user enabled. Tune its options as described in previous slide.

Check if suhosin is enabled for user. Tune its options as described here http://docs.cloudlinux.com/index.html?troubleshouting_mod_lsapi.html

If previous items do not help, contact helpdesk.cloudlinux.com

 

How to get lsphp core dump on crash

 

Configure mod_lsapi to allow lsphp to generate core dumps. In mod_lsapi.conf:

 

lsapi_backend_coredump On

 

Enable core file generation in sysctl:

 

sysctl -w ‘kernel.core_uses_pid=1’

sysctl -w ‘kernel.core_pattern=core.%p’

 

Configure system to change max size of core files. In /etc/security/limits.conf add:

 

user1 soft core unlimited

user1 hard core unlimited

 

where user1 is the username for which lsphp crashes.

 

If /etc/profile.d/limits.sh exists, look up for the following lines:

 

if [ "$LIMITUSER" != "root" ]; then

         ulimit -n 100 -u 35 -m 200000 -d 200000 -s 8192 -c 200000 -v unlimited 2>/dev/null

 

Substring “-c 200000” must be replaced with “-c unlimited”.

 

Add line ulimit -c unlimited into apachectl script just after another invokes of the ulimit command.

 

Do cold restart of Apache with the command like this:

 

service httpd stop; sleep 2; killall lsphp; service httpd start

 

You can make sure that ulimit for lsphp is changed to unlimited successfully with the following command:

 

cat /proc/PID/limits | grep ‘Max core file size’

 

where PID is a pid of any lsphp process. ps -u user1 | grep lsphp

 

Core dump of lsphp will be created in the DocumentRoot of the corresponding virtual server.

  On cPanel server it should map to /home/user1/public_html.

 

mod_lsapi is not included in output of httpd -M after installation and setup command for cPanel EasyApache 3

 

1. Check if the file /usr/local/apache/conf/conf.d/lsapi.conf exists and not empty;

 

2. Check if output of the command

 

cat /usr/local/apache/conf/httpd.conf | grep "/usr/local/apache/conf/conf.d/\*\.conf"

 

is not empty.

 

If it is empty:

 

1. Add to "include" section of /var/cpanel/conf/apache/main string:

 

"include": '"/usr/local/apache/conf/conf.d/*.conf"'

"include":

  "directive": 'include'

  "items":

...

    -

      "include": '"/usr/local/apache/conf/conf.d/*.conf"'

"listen":

 

2. Do:

 

mkdir -p /usr/local/apache/conf/conf.d/; cp /usr/share/lve/modlscapi/confs/lsapi.conf /usr/local/apache/conf/conf.d/lsapi.conf

 

3. Call:

 

/scripts/rebuildhttpdconf

/scripts/restartsrv_httpd