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.
Received on Thu Jan 23 2014 - 17:25:52 MST
This archive was generated by hypermail 2.2.0 : Thu Jan 23 2014 - 12:00:06 MST