> > if a server is killed (SIGKILL) during a "large" static file transfer, then >> the client is not notified by his browser that file has not been completely >> downloaded. On Win it just says it is not a valid Win32 application or >> corrupted or sth. >> Now I know this is not a general problem and a graceful restart is the way >> to go around this, but if I do an upgrade then proper restart is required, >> or at least I think I remember I had problems with graceful restart in such >> situations. >> > > Sending a SIGKILL is an unfriendly way to end a process -- it causes the > kernel to immediately terminate the process, without giving the process any > chance to clean up. SIGKILL is thus not one of the signals handled > specially by Apache HTTP Server. For a list of the signals that are handled > specially, see http://httpd.apache.org/docs/2.2/stopping.html >
Sending SIGKILL was just a way to simulate apachectl stop, which sends SIGTERM and then if after 10s some children still did not exit, parent sends SIGKILL to them. > If you'd like to completely stop Apache HTTP Server so you can manually > restart it later, then sending SIGWINCH will cause httpd to exit gracefully > after completing any current requests or after GracefulShutdownTimeout is > reached, whichever comes first. Alternatively, you can cause httpd to exit > more quickly, interrupting any current requests, by sending it a SIGTERM. I > don't know for sure if either of these will cause a TCP RST to be sent to > the client, but I think the odds are better than if you used a SIGKILL. > Thanks for the hint, SIGWINCH (or apachectl graceful-stop) does the trick. I still have to test it (namely if HTTPD with PHP and eAccelerator has any troubles being restarted that way) but this looks promising. Again, RTFM would be my friend - again:) Thanks again, b.
