On 01/22/2014 06:07 PM, Will Roberts wrote: > When we add/remove a user we push a new file over to the server and tell > squid to reconfigure itself. This can happen at most once a minute, > though usually it's much less frequent than that. If you reconfigure Squid often, consider investing in better reconfiguration support in Squid. The current reconfiguration handling is too "heavy", not really suitable for frequent reconfigurations. You may be disturbing user traffic every time you reconfigure. Alternatively, redesign your configuration to avoid the need for reconfiguring Squid when you add/remove users. > I've seen a lot of messages about closing old connections due to > lifetime timeout, is there any possibility that we're hitting a fd > limit? Or something else that would cause opening a connection to fail? If those messages appear during or right after reconfigure, it is probably a Squid bug (or lack of better hot reconfiguration support, to be precise). I think I have seen them too, but I am not sure. >> FATAL: dying from an unhandled exception: >> AddOpenedHttpSocket(s->listenConn) >> FATAL: dying from an unhandled exception: HttpSockets[NHttpSockets] < 0 >> >> I haven't seen anything on the list with that text, nor do I see any >> open issues in the bug tracker. What kind of additional information >> can I provide to help debug this? Ideally, you should file a bug report and provide the following info: 1) A cache.log file with debug_options set to ALL,9 and as few workers with as little traffic as possible, while still reproducing the above bug. The cache.log file should start when Squid starts and end when the FATAL messages are logged after a reconfigure attempt. 2) A squid.conf file used for #1 above. The simpler it is, the better. Please note that if you are using different ports for different SMP workers and/or excluding those ports from Coordinator, there will be fewer folks interested in helping you with this problem (simply because it lies outside what they think the intended SMP use model is). HTH, Alex.
