apache piped errorlogs and the fastcgi processmanager don't work together
fastcgi-rAR/[email protected] (Ton Hospel)
| Newsgroups | gmane.comp.web.fastcgi.devel |
|---|---|
| Organization | lunix confusion services |
| Message-ID | <[email protected]> |
In my current apache setup I have Errorlog as a pipe. When I shut down apache (apachectl stop), the fastcgi processmanager sometimes doesn't clean up the fastcgi processes. The reason is that at stop time apache will send SIGTERM to the errorlog process, which will exit. At that moment the apache process manager may still be exiting, and may still try to write something to the errorlog. However, the other side of the pipe is already closed, and the process manager will get a SIGPIPE, and the SIGPIPE handler is still SIG_DFL. So the fastcgi process manager immediately exits without sending SIGTERMs to the fastcgi processes its managing and erasing the communication sockets. So these programs keep running with their sockets still existing. When apache gets started again, fastcgi requests will in fact be handled by these still runing programs (they are still reachable over their sockets that still exist in the filesystem). But the processmanager doesn't know about them. Funny enough this problem disappears by itself after the first apachectl graceful, because from then on the fastcgi processmanager gets started with SIG_IGN as the default PIPE handler. The workaround I do for the moment is to always set the handler for SIGPIPE to SIG_IGN in the fastcgi process manager, but all this points to a number of design problems, some of which you could argue are apaches fault and some which are fastcgi issues really: - apache shouldn't really kill the errorlog program until all process that might want to say some last words are gone - The initial setup of the first fastcgi process manager and later ones are not the same (SIGPIPE handler is SIG_DFL or SIG_IGN) - The ability of fastcgi program listening to the filesystem sockets and handling requests without the processmanager being aware of them (if I want external fastcgi handlers i want to explicitely configure them) Independent of if any of these features gets fixed, I think it would be a good idea to always set SIGPIPE to IGNORE in the fastcgi process manager. ___________________________________ fastcgi-developers mailing list http://fastcgi.com/fastcgi-developers/