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.
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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
