Apache Fail to Load/Start

[yikin]

I'm having problem with my apache server. After viewing on the severity I have rebuild my apache but the problem still persist. I need help in resolving my server (


The support team hasn't reply to my support request

cPanel.net Support Ticket Number:

[LS_Drew]

I told them they'd have more problems like this...there's something WAY wrong. USR1 is not restarting Apache, it's leaving it dead.

cPanel.net Support Ticket Number:

[haze]

Do you get an error when you try and restart apache via SSH? You probably have a problem with your config, also check your logs. I would strongly recommend you hire an admin that knows what they are doing because if you can't figure this sort of thing out on your own, your asking for trouble.

cPanel.net Support Ticket Number:

[LS_Drew]

There aren't even any errors in my logs at all. It just dies dead.

It did it every time an account was created and terminated until we changed wwwacct and killacct to restart with HUP rather than USR1.

That still has it crashing every time anyone adds a sub, addon, or parked domain though.

cPanel.net Support Ticket Number:

[LS_Drew]

Just to ask...is this a dv2 box that this is happening on?

I'm just trying to figure out if something was wrong on their image CD or something.

cPanel.net Support Ticket Number:

[Tim Greer]

Cpanel messed up the alloc.c file in the Apache source to try and fix this alleged error with CGI processes in the new Apache 1.3.28 version. Personally, my tests show this is only related to (and caused by) the PHP/SuEXEC patch that Cpanel offers. Nonetheless, the alloc.c source file was modified and it's broken and with the wwwacct's killall -USR1 httpd command, it will only kill httpd, not restart it. I've reported this to Nick (regarding this patch that breaks it, and that it's not the solution anyway (for the CGI issue)--as far as I can tell) in the Apache bugzilla.

I can only reproduce this issue in Apache with the PHP/Suexec patches from the same site Cpanel gets the patch PHP/SUexec patch from (http://www.localhost.nl/patches/). I may be wrong about this being only related to Apache builds with this patch (though, I honestly can't produce this problem with any other builds!), but the alloc.c source has been modified in a manner that broke it. Now all Cpanel builds have a broken Apache source and will (at least--other problems exist--I won't get into that) cause -USR signals to kill httpd, and not do a graceful. You have to use HUP instead.

[LS_Drew]

Tim,

We don't run phpsuexec and didn't have that cgi problem that some have been complaining about, but we did have the USR1 problem.

This fixed it for us:


https://bugzilla.redhat.com/bugzilla...g.cgi?id=64683

Updating that RPM did the job. USR1 works properly now.

cPanel.net Support Ticket Number:

[Tim Greer]

Originally posted by LS_Drew
Tim,

We don't run phpsuexec and didn't have that cgi problem that some have been complaining about, but we did have the USR1 problem.

The fact that alloc.c was (is) modified, is what I was reporting as the cause, not the CGI report.

This fixed it for us:


https://bugzilla.redhat.com/bugzilla...g.cgi?id=64683

Updating that RPM did the job. USR1 works properly now. :)

Hmm, interesting. I'm thinking the RPM install would have updated this and not used the source with the modified alloc.c file. This patch is over a year old, I wouldn't imagine that would have been the problem??? In fact, it couldn't have; see below.

I don't experience this issue with Apache 1.3.28--nor do I experience it with the PHP/SuEXEC patch--only the Cpanel modified source with the alloc.c hack. Thus, this is the reason, and I believe the RPM simply overwrote this and fixed that issue. If you aren't sure, try using an unpatched alloc.c in the build and see if -USR1 works. (I bet it does).

cPanel.net Support Ticket Number:

[LS_Drew]

It was doing it with an apache build from before they added that patch, which is why I didn't think it was part of the problem.

You may be right. Guaranteed you're a lot better at figuring these things out than I am, but I do know this: after installing that RPM, it ain't crashin no mo'

I only had one machine doing this...the rest were fine. So if the old file was overwritten, I'm SOL for testing purposes.

cPanel.net Support Ticket Number:

[Tim Greer]

Crashing? Or just the kill and lack of a graceful restart? Anyway, I am doing some tests now to confirm this behavior and will post one way or the other as per the status shortly. Are you sure it was doing this prior to the alloc.c patch? Check your buildscript for the patch to see. I'll let you know in a few minutes what I can confirm or not, but I've not seen this signal fail to do what it should.... unless Cpanel is using a really outdated version of signames.h (which I don't think is the case).

cPanel.net Support Ticket Number:

[LS_Drew]

You're right, crashing isn't the right word. It just wasn't restarting with USR1. The HUP was working though. We changed wwwacct and killacct to use HUP so it wouldn't bring apache down every time an account was created. However, that still left us down everytime someone created a sub or an addon.

This started for us at 8am on Saturday. I can't check the build script because apache's been recompiled several times since then, but at that time, I don't believe the patch had been released yet. (I think they put it out on Sunday)

Sorry, my info is probably frustratingly sparse in some areas. I know you're a lot more experienced with troubleshooting these things than I am.

I'm glad you're looking at this. I was going to PM you about it yesterday and see if you knew anything about it, but I didn't want to bother ya.

cPanel.net Support Ticket Number:

[Tim Greer]

You are correct. My concern was the processed that should not have been killed, will now be killed (if the right situation is at hand), hence my issue with alloc.c patch. This seems like a quick fix for the wrong reason, but I very well may be wrong. I have not had time to look it all over yet. Also, as far as I can tell, only 1/2 the patch is needed (the one line) for this quick fix, and the other is for Win32, etc., if any use at all. Anyway, the -USR1 signal seems to be caused by a similar unrelated issue (as far as I can tell) along the same lines you mentioned. Cpanel claims that RPM is up to date, but you have to install it anyway. It sucks testing on servers you have no previous history with personally. This does appear to be related to how the hacks made to Apache are affecting this, since it was working fine for signaling other processes. I'll look into this more. Thanks.

cPanel.net Support Ticket Number:

[danielaugustus]

MY company was against the wall cause of this. I'm sure USR1 is ok for other processes. Just apache understand it wrong.

About 300 customers left this week.......

We are migrating to h-sphere most of the rest, just keeping the customers who really wants to stay with cpanel ( a great control panel, but i dont know why this is happening with it )....


:/ I'm now unhappy ..... I was mad uesterday. Now I'm just too tired ....

[Tim Greer]

This is very old news and a very dated thread. This problem hasn't existed for a while.

[danielaugustus]

Back again on some cases. dont know exactly where the fault is. Or redHAt kernel or cpanel ... or both