<div dir="ltr">After bumping Squid from 3.4.x to 3.5.x in our implementation of Squid in the Smoothwall Express v3.1 firewall distro we have begun to have complaints from our users about "erratic behavior" of Squid shutting down during reboots or network drops causing reboots.<br><br>It appears that squid (v3.5.[5-6]) does not respond well to SIGTERM 
during system shutdown; the cache index almost invariably needs to be 
rebuilt on next boot. It is suggested that we use squid to shut squid 
down. While using squid to stop the squid daemon is very doable, this 
requirement runs contrary to the longstanding, traditional UNIX method 
of "SIGTERM, pause, SIGKILL".<br><br>During normal system operation, 
squid *ought* to be able to take as much time as it wants to shut down. 
But it still shouldn't take more than 10-20 seconds; 'shutdown' is a 
command, not a request to be honored at squid's leisure. After all, the 
CPU could be on fire....<br><br>This raises a few questions that are 
intended to foster fresh discussion, not to re-hash old arguments. They 
are really more rhetorical in nature; the goal is to find the root cause
 of the problem.<br><ul><li>Why do these latest versions of Squid 3 behave oddly in this respect?</li><li>What is it about shutting squid down that corrupts the cache index?</li><li>Does it take more than a few seconds to write the index to disk?</li><li>Does squid use the very slow 'writethrough' method instead of trusting the Linux disk cache to properly save the cache?</li><li>Should squid write the cache index to disk more often?</li><li>Should squid track its own 'dirty pages' in its in-core index to reduce the time it takes to write the index?</li><li>Should squid implement a journal (akin to EXT/ReiserFS and others) so the on-disk index structure is always OK?</li><li>Is the problem related to clients actively receiving web pages from squid?</li><li>Could
 squid's signal handling be adjusted to treat those clients more 
harshly? That is, terminate the transfers early because squid shutting 
down is much the same as the network interface going down.</li><li>Is 
the only viable solution to use squid to stop the daemon? Does 'squid -k
 shutdown' exit only after the daemon is dead? The squid man page 
indicates that it sends the shutdown 'signal' but does not await a 
reply; thus a potentially lengthy pause in system shutdown may be 
required anyway.</li><li>Is pausing the system shutdown for 10-15 seconds the only really viable shutdown solution?</li><li>Or is it best to delete and rebuild the cache index on every system startup?</li></ul><p>Any thoughts on any of the above statements or issues?</p><p>As always, I appreciate any help and suggestions.</p><p>Regards</p><p>Stan<br></p><br></div>