Topic: Httpd crashing

[Peter]

Does someone know a fix for my chrashing httpd? I run e-smith 5.5 and very often my httpd crashes. I saw this was a issue in e-smith 5.0 and 5.1 (http://www.e-smith.org/bugs/index.php3?op=showBug&bugID=54) but it seems like the bug is still there. Anyway the suggested workaround as described on the buglist is "manually restarting the httpd daemon" is not an option, as you probably can imagine why.

This is a dump of what turns up in my httpd_errorlog after crashing:

[Tue Nov 26 10:08:39 2002] [notice] SIGUSR1 received.  Doing graceful restart
[Tue Nov 26 10:08:40 2002] [notice] Apache configured -- resuming normal operat
ions
[Tue Nov 26 10:08:40 2002] [notice] suEXEC mechanism enabled (wrapper: /usr/sbi
n/suexec)
[Tue Nov 26 10:08:40 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)

Thanks,

Peter

[Jáder Marasca]

Hi,

I also had had very often httpd crash... but just in a couple of sites. Other ones never had this problem.
What do you think if we start to compare packages installed on this problematic sites?
My first guess is NTOP! Do you have it installed?

[Peter]

No,

I have one site running with the PHPWebsite package from Appalachian (0.8.3). Could be that this site causes all the trouble. However there aren't any bugs or know problems on the PHPWebsite support forums which can be related to my problem.

Grt.

Peter

[Jáder Marasca]

I´m sorry my server hadn´t that PHPWebsite package...
In fact I never heard about it... I´ll look around to discover what it does!
Neither do you have installed NTOP ?

Jáder

[Harvey]

Mine crashes every week:

Every sunday, the httpd web server goes down on it's own and doesn't restart, but other services don't seem to be affected.

It's not my hardware, my ISP or anything like that.  I'm sure that it's the software because it's predictable.

Maybe it's a cron.weekly thing?

[Harvey]

Are any of you running RAV Antivirus or using PPPoE connections?

[Jáder Marasca]

No I´m running on a cable modem connection and on a ADSL non-fixed ip (PPPoA) connection with this problem from time to time...
none of them has RAV ...

Sorry!

[Harvey]

I just added this to my /etc/cron.d directory:

0 * * * * root /etc/rc.d/rc7.d/S85httpd-e-smith restart > /dev/null 2>&1

I saved the file as "restart-httpd.rc" and it will attempt to restart the web server every hour.

It's not elegant, but hopefully this will prevent too much down time.

See: http://www.e-smith.org/bboard//read.php?f=1&i=6821&t=6818

[Peter]

Jader,

http://phpwebsite.appstate.edu for the PHPWeb portal software.

Maybe it's this package that is causing the trouble since I discovered errors in my messages log that indicates it is trying to include PEAR extensions that cannot be found, because the include path to the PEAR extensions is wrong. These errors occur on about the same time the httpd daemon crashes.

[Peter]

Also very suspicious are the Nimda/Code red attacks on my webserver before every unexpected shutdown of my httpd daemon...

Grt.
Peter

[Guck Puppy]

Are you saying that it crashes after EVERY codered/nimda attack? Or not.

[Peter]

According to my httpd error_log this is in 3 of 4 times the case unfortunatly.

[guestHH]

Hi,

Try installing Snort Acid for the time being. It will prevent 'unauthorised' actions.

Darrel has a contrib for that (beta but working)

Please post your results to us as wel as Mitel (security@e-smith.com)

Regards,
guestHH

[Arkman]

I had this exact same 'crash' just moments ago. I'm not positive why it happened yet, but it appeared to happen when using IMP to send a  mail with a large attachment. IMP froze on sending the email and then 'wham-o' no more httpd. It might just be a coincidence, but I think I've seen this one other time as well under the same circumstances. Will try to reproduce on my test server in the AM and post back.

-Arkman

[Arkman]

My bad...different crash, but it was related to IMP and file size attachment.

[Jesper]

I have had the excact same expirience and I happends every time I send emails with large attachments via the web interface. This does NOT happen when I use SMTP/POP via f.ex OutLook.

[Jáder Marasca]

And what is the configurated max attach size on PHP?
Had you seen Dan Brown How to about max attach size on Horde/IMP ? And for the 5.5 SME there is a how to on SME page...

Shouldn´t this to be the problem... it´s a bug... when you try to send a BIG attach (beyond configurated) it crashes !

What did you  think about this ? (It´s sh**t or make a little sense!)

[Jesper]

Actually I haven't changed the max attachment size from default (whatever it is). My attachment, when it crashes, is just around 1Meg - That should be below any default limit I should think.

[Jáder Marasca]

The default limit is 2MB!

So I don´t any any clue about why do you get that strange behaviour!

[Peter]

Gents,

I'm investigated my problem past week and something interesting turned up from my messages log:

kernel: eth1: Abnormal interrupt, status 00000020

Everytime I experience problems when accessing my webserver from outside the local network this messages turns up. Significantly it only seems to happen when the connection is under some load.

I'm using an Realtek ethernet adapter with chipset RTL-8139C. Used both realtek drivers already (rtl8139 & 8139too) that where avilable on SME 5.5 but did not help.

Is this a driver issue in combination with kernel 2.2.19 as some newsgroups suggest? Is there anybody who have experienced the same problem?

Grt.

peter

[Jesper]

Interesting. I am using the same driver/adapter.

I had a look at my log and found the following entries when I died. My attachment was 1.2Meg.

11:23:21 server httpd: PHP Fatal error:  Allowed memory size of 8388608 bytes exhausted (tried to allocate 1741735 bytes) in /usr/share/pear/Net/SMTP.php on line 207
Dec  6 11:23:21 server httpd: PHP Fatal error:  Allowed memory size of 8388608 bytes exhausted (tried to allocate 32 bytes) in /usr/share/pear/PEAR.php on line 509
Dec  6 11:23:21 server httpd: PHP Fatal error:  Allowed memory size of 8388608 bytes exhausted (tried to allocate 140 bytes) in Unknown on line 0

/Jesper