Just tested this on worker apache and all children exists like they should when parent gets a kill -9. I don't have prefork available so didn't test it since I don't understand how it would be related to this. Even if prefork had the same problem, is the goal of this project to have the same problems as prefork?
Hannes On 3 February 2011 15:42, Marcelo Coelho <[email protected]> wrote: > Hi Hannes, > > What happens when you do this with a prefork apache? > > On Feb 3, 2011, at 12:37 PM, Hannes Landeholm wrote: > > > Seeing this problem again. Please fix this problem. Here's a test case: > > > > 1. Start Apache with Peruser MPM. > > 2. Run some requests on a couple of processors. > > 3. A bunch of apache children has now started. > > 4. Kill the main process with signal 9. > > > > What happens: > > > > - The children now refuses to exit although their parent is dead. If one > or more of them is multiplexers they will block apache from restarting by > holding on to the listen handle for the port 80 socket making it impossible > to restart the server unless you go trough all zombie children and kill them > manually one by one. > > > > What I expected: > > > > - The children notices that the parent are dead and exit. > > > > Please fix this problem. I suggested a way to do it but I have no idea if > that'd fix it permanently or if it'd be an ideal solution. > > > > Thanks. > > > > Hannes > > > > > > On 26 January 2011 10:26, Hannes Landeholm <[email protected]> wrote: > > Just wanted to add a note to this. > > > > I installed the long lost children patch yesterday and since then I > haven't seen this problem. > > > > Regards, > > > > Hannes > > > > > > On 25 January 2011 17:49, Hannes Landeholm <[email protected]> wrote: > > To fix this I suggest changing the line in peruser.c:2111 > > > > ret = apr_poll(pollset, num_listensocks, &n, 1000000); > > > > so it gets a time out of 1000000 (one second). And below it do a check > > if the main process is still running. If not, quit. > > > > Hannes > > > > > > On 25 January 2011 16:56, Hannes Landeholm <[email protected]> wrote: > > > Oh yeah, and it's even worse since my automatic watchdog script > > > doesn't even know apache doesn't work anymore since it sees alive > > > httpd processes running and think everything is hunky dory. > > > > > > Hannes > > > > > > On 25 January 2011 16:55, Hannes Landeholm <[email protected]> > wrote: > > >> Hi, > > >> > > >> I see a whole bunch of loose children that are stopped and refuse to > > >> exit even though their parent process has died a long long time ago. > > >> This has happened multiple times. I think it happens when the parent > > >> exits ungracefully like when it's crashed. Can you add a check that > > >> terminates child processes when the parent is killed? This is > > >> exceptionally annoying when multiplexers do this since they block > > >> apache from restarting as they block the listen port. Since not even > > >> automatic watchdog scripts can bring back apache to life when that > > >> happens I'd say this is a critical/major bug. > > >> > > >> Here's a backtrace for one of the borked kids: > > >> > > >> #0 0x00007f04fd20ef58 in *__GI___poll (fds=0x7fffe4e50740, nfds=2, > > >> timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83 > > >> #1 0x00007f04fdd3c230 in apr_poll (aprset=0x1c44670, num=2, > > >> nsds=0x7fffe4e508c8, timeout=-1) at poll/unix/poll.c:120 > > >> #2 0x000000000046c0da in child_main (child_num_arg=<value optimized > > >> out>) at peruser.c:2111 > > >> #3 0x000000000046cfe9 in make_child (s=0xd34b38, slot=14) at > peruser.c:2534 > > >> ... > > >> > > >> It's also proably related to the earlier mutex warning/critical child > error. > > >> > > >> Hannes > > >> > > > > > > > > > _______________________________________________ > > Peruser mailing list > > [email protected] > > http://www.telana.com/mailman/listinfo/peruser > > _______________________________________________ > Peruser mailing list > [email protected] > http://www.telana.com/mailman/listinfo/peruser >
_______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
