The issue with squid is that we have a 'control' process (the one whose PID is saved in /var/run/squid.pid), which does nothing but controlling other processes (real squid workers, authenticators, redirectors).
Sending a TERM signal to the control process tells him to gracefully shut down every process he controls, waiting for connection timeout on both client-side and server-side. This may take a long time since ongoing connections are not terminated but completed (i.e. if a page is in transfer, squid will wait for the transfer to complete). The last process that is shut down is the on-disk storage module, which needs to be up while traffic is flowing through squid. > 1. 120 seconds is a _long_ time to wait for a service to shut down. > Is the initscript waiting too long? If there are no active connection, yes. On the other end this bug is just about knowing that squid has shut down. What happens after 120 secs is that the initscript will return an error and squid will keep shutting down. When all connections are closed or timeout'ed squid will correctly exit. So maybe we should wait forever... > 2. After some period of time, should the initscript not attempt to > kill squid again? After some period of time, should the > initscript not kill squid with SIGKILL? This would kill the control process, leaving squid in a really bad state. > Please note that start-stop-daemon has a very useful "--retry" feature > with which initscripts can perform escalating kills. The pdnsd and > dnsmasq initscript are good examples to follow. The only thing we could do is 'squid -k kill' that will kill all squid working processes and exit. I don't know if this would keep squid from reconstructing the whole cache at restart. Regards, -- Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]> GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26
signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
