[RESOLVED] LSWS 4.0.13 - Signal 9's gone... Signal 15's new

At [27/Feb/2010:07:11:38 -0500], web server with pid=24638 received unexpected signal=15, no core file is created. A new instance of web server will be started automatically!

Code:

At [27/Feb/2010:13:02:14 -0500], web server with pid=14126 received unexpected signal=15, no core file is created. A new instance of web server will be started automatically!

Code:

At [27/Feb/2010:22:18:42 -0500], web server with pid=16181 received unexpected signal=15, no core file is created. A new instance of web server will be started automatically!

Code:

At [28/Feb/2010:01:01:15 -0500], web server with pid=22155 received unexpected signal=15, no core file is created. A new instance of web server will be started automatically!

Code:

At [28/Feb/2010:13:01:27 -0500], web server with pid=28935 received unexpected signal=15, no core file is created. A new instance of web server will be started automatically!

Code:

At [28/Feb/2010:14:08:16 -0500], web server with pid=14474 received unexpected signal=15, no core file is created. A new instance of web server will be started automatically!

After talking with Tony I found that changes were made in 4.0.13 that would help fix the cPanel 11.25/LSWS 4.0.13 Signal 9 kills that were happening from time to time... I pushed this update to all servers and all of them it's been working beautifully but this single one.

This server is the only one pushing this Signal 15 out of about 20 servers running LSWS 4.0.13.

Signal 9 will cause much bigger problem than signal 15, and it is the biggest headache for us. We will try to figure something out from cPanel's Apache restart script/binary. Hopefully, we can figure out a satisfactory solution soon.

Let us try to make it work better first.
We got complains from cPanel manager that their support department got too much support requests related to LiteSpeed, that's why we have to add a disclaimer every where stating that we are responsible for LiteSpeed related support issues.

After all, they should allow the (smooth) support of 3rd party replacements for Apache.

Click to expand...

Well I gave cpanel a piece of my mind on the logic they're using. Unfortunately talking to them is useless you're talking to a developer is getting you nowhere.

This file:

/usr/local/cpanel/Cpanel/HttpUtils/ApRestart.pm

It's quite a gem Line 358 and onward.

They use a regex against httpd processes ran by root or nobody.

That's how it determines pid's which if you do say "vim httpd" then leave it open for most of the day I imagine you'll get hit by a signal 9 eventually.

Now this logic is not new it's been there for quite a while. What is new is them trying to address httpd processes that do not die on Apache restarts. So now they're getting anything httpd in the cross fire. There is more logic in why it does it and it thinks lsws is not restarting sometimes I imagine.

So I guess someone could complain to them saying I run a script called httpd and cPanel issues kill 9 at it all the time. Then maybe they might re-think how they determine the pid's of Apache.

Go through the code, looks like that as long as we make _check_ap_restart() function happy, we are good.

Looks like this script is only for restart/graceful-restart, maybe there is another piece of code for forced stop, start sequence?

Click to expand...

That would appear to be the logical location for it all to start in. Although I'm sure the safeapacherestart binary has a lot of interesting aspects in it. As there is a log file /usr/local/cpanel/logs/safeapacherestart_log which only some of the log writing from ApRestart.pm others are not from it.

I think it's pretty safe to assume though it thinks lsws is not always gracefully restarting. I wish I knew why though my best guess is when multiple restarts are issued around the same time it's probably happening. As doing things that are restart heavy seem to cause it the most issues. So doing account restores in cPanel cause them in a lot of cases but normal usage you might see one every few days.