DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42580>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42580 ------- Additional Comments From [EMAIL PROTECTED] 2008-02-11 14:47 ------- Created an attachment (id=21511) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21511&action=view) Patch When I had the following settings : Listen 192.168.21.1:81 Listen 192.168.22.1:81 <IfModule worker.c> ListenBackLog 50000 StartServers 2 ThreadLimit 5 ThreadsPerChild 5 MinSpareThreads 1 MaxSpareThreads 1 ThreadsPerChild 5 MaxClients 10 MaxRequestsPerChild 0 </IfModule> I was getting the following error in my error log [Mon Feb 11 13:33:52 2008] [error] (70007)The timeout specified has expired: apr_pollset_poll : (listen) On debugging, I found out that the listener thread calls port_getn to listen for new connections, it was getting SIGHUP signal. This was confirmed by truss output. 5541/1: read(6, 0xFFFFFD7FFFDFF38B, 1) (sleeping...) 5541/7: lwp_park(0x00000000, 0) (sleeping...) 5541/6: lwp_park(0x00000000, 0) (sleeping...) 5541/5: lwp_park(0x00000000, 0) (sleeping...) 5541/4: lwp_park(0x00000000, 0) (sleeping...) 5541/3: lwp_park(0x00000000, 0) (sleeping...) 5541/8: port_getn(12, 0x00539D30, 2, 1, 0x00000000) (sleeping...) 5543/1: read(6, 0xFFFFFD7FFFDFF38B, 1) (sleeping...) 5543/3: lwp_park(0x00000000, 0) (sleeping...) 5543/4: lwp_park(0x00000000, 0) (sleeping...) 5543/5: lwp_park(0x00000000, 0) (sleeping...) 5543/6: lwp_park(0x00000000, 0) (sleeping...) 5543/7: lwp_park(0x00000000, 0) (sleeping...) 5543/8: fcntl(11, F_SETLKW, 0xFFFFFD7FFF241E10) (sleeping...) 5539/1: pollsys(0xFFFFFD7FFFDFF2E0, 0, 0xFFFFFD7FFFDFF3A0, 0x00000000) = 0 5539/1: write(7, " !", 1) = 1 5541/1: read(6, " !", 1) = 1 5541/1: lwp_wait(2, 0xFFFFFD7FFFDFF31C) = 0 5541/1: lwp_kill(8, SIGHUP) = 0 5541/1: lwp_kill(8, SIG#0) = 0 5541/8: Received signal #1, SIGHUP, in port_getn() [caught] 5541/8: siginfo: SIGHUP pid=5541 uid=101 code=-1 5541/8: port_getn(12, 0x00539D30, 2, 1, 0x00000000) Err#4 EINTR 5541/8: lwp_sigmask(SIG_SETMASK, 0xFFBEE007, 0x0000FFF7) = 0xFFBFFEFF [0x0000FFFF] Note that 5541/8 is the listener thread and 5541/1 was sending the SIGHUP signal. I further debugged why one of my process is dieing. Then I found out that in worker.c, in perform_idle_server_maintenance function, if (idle_thread_count > max_spare_threads) { /* Kill off one child */ ap_mpm_pod_signal(pod, TRUE); idle_spawn_rate = 1; .. >From debugging, I found out that idle_thread_count was set to 10 and max_spare_threads was set to 6. Hence the first thread was sending SIGHUP signal to kill the process. If I increase the MaxSpareThreads to 10 then this error disappeared because in that case, worker process didn't try to kill himself. <IfModule worker.c> ListenBackLog 50000 StartServers 2 ThreadLimit 5 ThreadsPerChild 5 MinSpareThreads 1 MaxSpareThreads 10 ThreadsPerChild 5 MaxClients 10 MaxRequestsPerChild 0 </IfModule> The error message is misleading and it may or may not appear. It depends on the timing. If listener thread has been reached to the point when it is blocked with port_getn then we get this error. It seems to me that server wanted to deliberately kill one of the child process. Casue of the problem is that apr_pollset_poll function doesn't differentiate the EINTR and ETIME. apr_pollset_poll contains ... if (errno == ETIME || errno == EINTR) { rv = APR_TIMEUP; } In worker.c, we do expect EINTR to be normal as shown below : -------------- worker.c -------------------------- rv = apr_pollset_poll(pollset, -1, &numdesc, &pdesc); if (rv != APR_SUCCESS) { if (APR_STATUS_IS_EINTR(rv)) { continue; } -------------------------------------------------- If we allow EINTR as a known error and return APR_EINTR as given in suggested patch then this error disappeared. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
