when apache can't kill a child process during shutdown

i still had a debugger attached, so even 9 didn’t do the trick šŸ™‚

[Fri Jul 21 23:37:04 2006] [warn] child process 31751 still did not exit, sending a SIGTERM
[Fri Jul 21 23:37:04 2006] [warn] child process 31751 still did not exit, sending a SIGTERM
[Fri Jul 21 23:37:05 2006] [warn] child process 31751 still did not exit, sending a SIGTERM
[Fri Jul 21 23:37:10 2006] [error] child process 31751 still did not exit, sending a SIGKILL
[Fri Jul 21 23:37:26 2006] [error] could not make child process 31751 exit, attempting to continue anyway
[Fri Jul 21 23:37:26 2006] [notice] caught SIGTERM, shutting down

Unfortunately, the debugger wasn’t responding any more, and while I could kill the debugger, it’s left the process (which still has my port 80 bound) stuck in a syscall (and can’t connect to it from a new gdb), so I may be out of luck in getting real http traffic served again (at least on 80) without a reboot since the process is stuck sTopped.

% ps auxwww|grep apac
www-data 31751  0.0  3.4  15452  8748 ?        T    21:51   0:00 /usr/sbin/apache2 -k start -DSSL
% sudo netstat -pnl|grep :80
tcp6       0      0 :::80                   :::*                    LISTEN     31751/apache2

[Later] Ok, actually, it turns out this particular process was stuck in a syscall (for some reason i though being in a syscall would be a different process state) waiting on traffic from a stuck client – once i killed the socket on the client machine (taking down its network interface), the apache2 process returned back to user space and died fine.  So, I didn’t have to reboot.

This makes me wonder where Linux is these days with interruptible syscalls (I could assume based on this data point, but that may be unfair), though.

Advertisements