"httpd -n" processes load Litespeed

[Arthur L]

Hello,

We have several servers which overloaded by subprocess "httpd -n 89':

~]# ps xauf | grep http
root      522971  6.6  0.2 225664 198368 ?       S    09:57   0:13 litespeed (lshttpd)
root      522977  0.0  0.0  16928   804 ?        S    09:57   0:00  \_ httpd (lscgid)
nobody    523339  1.3  0.2 241896 197588 ?       Dl   09:57   0:02  \_ litespeed (lshttpd)
nobody    523340  4.5  0.2 326540 205824 ?       Sl   09:57   0:08  \_ litespeed (lshttpd)
root      527366 98.8  0.0  16932   984 ?        R    10:00   0:18      \_ httpd -n 89

We've tried to kill it manually, however it reappears immediately and loads again. We also have several servers with the sam configuration (cPanel + CloudLinux + Litespeed), same CPU and RAM, less of clients, which are working properly without "httpd -n"

Can someone take a look and suggest how it can be resolved? Thanks

 

[mistwang]

Are you using the latest version? 5.1.13?

 

[Arthur L]

Hey, yes, all Litespeed installations are updated to 5.1.13

 

[NiteWave]

there is a similar user case some days ago.
the reason was LVE failure, can find some error messages in /usr/local/apache/logs/error_log and stderr.log

the root cause of this case was disk quota exceeded for many accounts and caused LVE failure. the host only assign about 250M(?) to each account. your case may vary. but please check error_log and stderr.log to search LVE related messages.

 

[Arthur L]

there is a similar user case some days ago.
the reason was LVE failure, can find some error messages in /usr/local/apache/logs/error_log and stderr.log

the root cause of this case was disk quota exceeded for many accounts and caused LVE failure. the host only assign about 250M(?) to each account. your case may vary. but please check error_log and stderr.log to search LVE related messages.

thanks, seems like it's worked. we've found out several accounts reached their disk and inode quotas. no httpd -n processes for now and litespeed working properly.

however, can it be reported to CloudLinux developers? as you mentioned, there was a user with the same problem, so it can be a global issue.

 

[Pong]

yes, It is good if you can report back to CloudLinux developers. We encouraged the user to do the same last time.

 

[plusplus]

Im having the same issue, reported to CL, lets see...

 

[NiteWave]

please search stderr.log, see if there is message like following:
2017-01-26 15:26:27.864 [STDERR] lscgid (910647): LVE jail(1374) ressult: -1, error: Unable to create directory /home/xxxxx/.cagefs/opt/alt/php71/link (Disk quota exceeded) !

 

[Arthur L]

Guys, I hope this will be helpful to resolve the issue at hand. We've contacted CloudLinux support and they suggest to use the following solution (works for "xfs" servers, "ext3/ext4" should be resolved per - https://www.cloudlinux.com/cloudlin...anager-cagefs-liblve-and-python-cllib-updated)
=====================
I would like to say that the problem 'LVE jail ressult: -1, error: Unable to create directory' has been fixed in older liblve/cagefs: https://www.cloudlinux.com/cloudlin...anager-cagefs-liblve-and-python-cllib-updated . However it also depends on filesystem used, the fix was fully applied for ext4 , but xfs is much different and the fix was implemented on in CloudLinux7 / CL6hybrid kernel.

As of now to have it fixed please try to set cap_res_quota_disable option to 1:
echo 1 > /proc/sys/fs/xfs/cap_res_quota_disable
=====================