[squid-users] SIGTERM SIGKILL causes issues with squid shutdown during reboot

[Stanford Prescott]

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.

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".

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....

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.

   - Why do these latest versions of Squid 3 behave oddly in this respect?
   - What is it about shutting squid down that corrupts the cache index?
   - Does it take more than a few seconds to write the index to disk?
   - Does squid use the very slow 'writethrough' method instead of trusting
   the Linux disk cache to properly save the cache?
   - Should squid write the cache index to disk more often?
   - Should squid track its own 'dirty pages' in its in-core index to
   reduce the time it takes to write the index?
   - Should squid implement a journal (akin to EXT/ReiserFS and others) so
   the on-disk index structure is always OK?
   - Is the problem related to clients actively receiving web pages from
   squid?
   - 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.
   - 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.
   - Is pausing the system shutdown for 10-15 seconds the only really
   viable shutdown solution?
   - Or is it best to delete and rebuild the cache index on every system
   startup?

Any thoughts on any of the above statements or issues?

As always, I appreciate any help and suggestions.

Regards

Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150723/3ba679ff/attachment.html>