httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Kaluža <jkal...@redhat.com>
Subject Re: prefork mpm crashes on SIGINT [possible patch?]
Date Thu, 14 Aug 2014 14:22:36 GMT
Hi,

I'm resurrecting this old thread, because I hesitate to do changes in 
signal handling without any ack of someone else.

This bug is more problematic in the context of docker [1] where people 
tend to run "httpd -DFOREGROUND", because in docker, you should run 
applications on foreground and docker will manage the application itself.

Note that from time to time depending on luck, this is reproducible even 
without any load and the server. Just "httpd -DFOREGROUND" and then ctrl+c.

[1] https://www.docker.com/

Is anyone against the patch I sent last year in previous email in this 
thread below?

Regards,
Jan Kaluza

On 05/09/2013 09:03 AM, Jan Kaluža wrote:
> I think I have proper solution for the crashes mentioned in previous
> mail (see the attached patch):
>
> 1. Ignore SIGINT and SIGTERM in clean_child_exit. Handlers of these two
> signals would call clean_child_exit again and there is no reason to
> handle them once we are exiting.
>
> 2. Ignore SIGINT completely in children. I'm not sure I see valid
> use-case in sending SIGINT to child process, but it's causing crashes
> when running with -DFOREGROUND. See the comment in attached patch for
> more info.
>
> I was not able to reproduce the crash with this patch.
>
> On 05/07/2013 08:37 AM, Jan Kaluža wrote:
>> Hi,
>>
>> to reproduce it, I start httpd-2.4.4 like this:
>>
>> /usr/sbin/httpd -k start -DFOREGROUND
>>
>> and in another terminal I run ab like this:
>>
>> ab -n 150000 -c 4 http://127.0.0.1/index.php
>>
>> Index.php is just dummy script with phpinfo.
>>
>> When "ab" is benchmarking, I kill httpd using "ctrl+c". In 4/10 tries it
>> crashes with following backtrace [1].
>> If gdb does not lie, there is race condition in signal handling. I'm not
>> sure if anything changed in this code between 2.2 and 2.4, but it looks
>> like 2.2 was handling this situation somehow better. I think this
>> situation can lead to various problems like deadlocks.
>>
>> I've been able to workaround this using the attached patch, but I don't
>> think this is the best way how to fix this problem. It would be better
>> to find out why there are more signals called in a row as a result of
>> single SIGINT signal sent to main process.
>>
>> I will try to do that myself, but I was thinking there could be people
>> more familiar with this part of code and with httpd's children lifecycle
>> reading this list.
>>
>> [1]
>>
>> #0  0x00007fe74b7d2ba5 in raise () from /lib64/libc.so.6
>> #1  0x00007fe74b7d4358 in abort () from /lib64/libc.so.6
>> #2  0x00007fe74b81259b in __libc_message () from /lib64/libc.so.6
>> #3  0x00007fe74b819a8e in _int_free () from /lib64/libc.so.6
>> #4  0x00007fe74bf8e85c in allocator_free (node=0x7fe74bb4e798
>> <main_arena+88>, allocator=0x7fe74e7ab670) at memory/unix/apr_pools.c:430
>> #5  apr_pool_destroy (pool=0x7fe74e7ab768) at memory/unix/apr_pools.c:856
>> #6  0x00007fe74308c1be in clean_child_exit (code=code@entry=0) at
>> prefork.c:218
>> #7  0x00007fe74308c9cb in just_die (sig=<optimized out>) at prefork.c:344
>> #8  <signal handler called>
>> #9  0x00007fe74d06d541 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
>> #10 0x00007fe74b7d5df1 in __run_exit_handlers () from /lib64/libc.so.6
>> #11 0x00007fe74b7d5e75 in exit () from /lib64/libc.so.6
>> #12 0x00007fe74308c1db in clean_child_exit (code=code@entry=0) at
>> prefork.c:227
>> #13 0x00007fe74308c5f5 in child_main
>> (child_num_arg=child_num_arg@entry=2) at prefork.c:725
>> #14 0x00007fe74308c94c in make_child (s=0x7fe74e5a5368,
>> slot=slot@entry=2) at prefork.c:800
>> #15 0x00007fe74308c9a6 in startup_children (number_to_start=3) at
>> prefork.c:818
>> #16 0x00007fe74308d856 in prefork_run (_pconf=<optimized out>,
>> plog=0x7fe74e5d74f8, s=0x7fe74e5a5368) at prefork.c:976
>> #17 0x00007fe74d2a5d4e in ap_run_mpm ()
>> #18 0x00007fe74d29f3fa in main ()
>>
>> Thanks for help,
>> Jan Kaluza
>
> Regards,
> Jan Kaluza


Mime
View raw message