Bug 117173 - SIGHUP crashes httpd
Summary: SIGHUP crashes httpd
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 1
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-03-01 06:37 UTC by Corey T.
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-06-10 08:16:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
acess_log and error_log of the crash (11.83 KB, text/plain)
2004-03-01 06:38 UTC, Corey T.
no flags Details
core dump of an httpd seg fault (512.24 KB, application/octet-stream)
2004-04-13 01:50 UTC, Corey T.
no flags Details

Description Corey T. 2004-03-01 06:37:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8

Description of problem:
This keeps happening to me frequently. It seems some idiotic person
keeps DOSing my server by passing a strange query to httpd

After this string is passed a couple times, it seems to cause httpd to
crash.

It's weird though because though a seg fault occurs in the parent
process, looking at the log time stamps, httpd still seems to service
some requests after the seg fault occurs, perhaps some children
processes don't get terminated right away for some reason? Also, if
httpd crashes in this way, shouldn't it restart automatically?

The server crashes every other day or so, I'm pretty sure these
strange queries are the cause of it.

I attached the last portions of my access_log and error_log where the
crash and strange queries occur.

Version-Release number of selected component (if applicable):
httpd-2.0.48-1.2

How reproducible:
Didn't try

Steps to Reproduce:
1. I imagine by passing those weird queries listed above, one could
reproduce the crash, though I haven't tried yet
2.
3.
    

Additional info:

Comment 1 Corey T. 2004-03-01 06:38:25 UTC
Created attachment 98152 [details]
acess_log and error_log of the crash

Comment 2 Joe Orton 2004-03-01 09:07:06 UTC
The crash was triggered by the logrotate run at 4am, and is highly
likely to be unrelated to the query strings which are targetting IIS
servers.   To diagnose further we need a core dump when the parent
crashes; to generate a core dump, run:

echo "ulimit -c unlimited" > /etc/init.d/httpd
echo "CoreDumpDirectory /tmp" > /etc/httpd/conf.d/coredump.conf

and then restart the server; then, next time the server segfaults like
this, a core file will be generated in /tmp.

Comment 3 Corey T. 2004-03-28 17:53:08 UTC
The server is still crashing in the same way, but I can't seem to get 
it to generate a core file in /tmp. I executed the command: 
echo "CoreDumpDirectory /tmp" > /etc/httpd/conf.d/coredump.conf

But the first command: echo "ulimit -c unlimited" > /etc/init.d/httpd
doesn't seem to make sense to me. Wouldn't that just 
overwrite /etc/init.d/httpd with a file that contains "ulimit -c 
unlimited"? I don't see the point of this. Please explain.

Comment 4 Corey T. 2004-04-05 01:07:42 UTC
I found this crash of httpd to be caused by the following command in
/etc/logrotate.d/httpd:

/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true

If I run the command /bin/kill -HUP `cat /var/run/httpd.pid` in the
shell, httpd crashes everytime. I will try to produce a core dump file
and attach it here. It seems httpd has problems restarting after the
HUP signal.

Perhaps this could also be seen as a logrotate bug because maybe the
above command is not the most intelligent way to restart apache.
Instead why not issue the command:

/etc/init.d/httpd restart

I will go ahead and file a bug at apache.org. I imagine this may not
be a Fedora specific bug.

Comment 5 Corey T. 2004-04-05 03:27:54 UTC
I also just notice that issuing the command:

apachectl restart

Also crashes the server. The log says:

[Sun Apr 04 21:23:57 2004] [notice] SIGHUP received.  Attempting to
restart
[Sun Apr 04 21:23:58 2004] [notice] seg fault or similar nasty error
detected in the parent process

Weird. Still can't figure out how to generate a core dump file. I trie
d putting CoreDumpDirectory /tmp in httpd.conf. But no core file shows
up in /tmp when httpd crashes.

Comment 6 Joe Orton 2004-04-05 09:32:46 UTC
OK, the simplest thing if you can reproduce this on demand is:

# service httpd stop
# ulimit -c unlimited
# /usr/sbin/httpd
### sleep whilst httpd starts up
# apachectl restart

which should get a core dump in /tmp.



Comment 7 Corey T. 2004-04-06 04:32:36 UTC
I tried the above sequence of commands and am able to crash the
server, yet it still won't generate a core dump file! I'm not sure
what to do at this point.

Comment 8 Corey T. 2004-04-13 01:50:35 UTC
Created attachment 99349 [details]
core dump of an httpd seg fault

Finally managed to generate a core file. Attached.

Comment 9 Joe Orton 2004-05-11 14:46:52 UTC
SIGILL is a strange error to terminate the parent...

"Program terminated with signal 4, Illegal instruction."

are you using any third-party modules?

Comment 10 Corey T. 2004-05-17 05:23:36 UTC
The only module I installed was the PHP 5 betas and RCs (from source)
from www.php.net. Currently I am running PHP 5 RC2, last time I
experienced this crash was when I was running PHP 5 RC1, I haven't
tried to reproduce the crash since I installed RC2, I will try to
reproduce the crash again and I will report my results back here.

Comment 11 Joe Orton 2004-05-17 08:12:30 UTC
There was a known issue affecting recent PHP releases which caused
segfaults on httpd SIGHUP, it's possible this is related.  The patch is:

http://www.apache.org/~jorton/php-4.3.6-pcrealloc.patch

it might need adjusting for PHP 5.

Comment 12 Daniel Draper 2004-06-10 05:10:56 UTC
The Bug appears to be caused by PHP 5. PHP 5 RC3 fixed the issue.
After installing, httpd stays alive after a SIGHUP. There will
probably be an RPM for php 5 when it is release.

DD

Comment 13 Joe Orton 2004-06-10 08:16:49 UTC
OK, thanks for letting us know.


Note You need to log in before you can comment on or make changes to this bug.