On 30/09/2013 8:26 p.m., Kris Glynn wrote:
Thanks Amos, that explains helper activity in the cache.log around rotate time.
When the problem occurred I didn't run a mgr:ntlmauthenticators report but on
one of the proxies just now it has 77 shutting down state and report is here -
http://pastebin.com/jhaFeW9H
Regards
- Kris Glynn: (07) 3295 3987 - 0434602997
-----Original Message-----
From: Amos Jeffries [mailto:[email protected]]
Sent: Monday, 30 September 2013 5:17 PM
To: [email protected]
Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5
On 30/09/2013 7:26 p.m., Kris Glynn wrote:
Getting back to the initial problem.. I first discovered it when users reported they couldn't authenticate to
one of the proxies, when I logged into the squid server the cache.log was full of errors like "WARNING:
external ACL 'ldap_group' queue overload. Using stale result" - when I dug further I noticed at the top
of the cache.log (after the nightly squid -k rotate) it had entries such as "ipcCreate: fork: (12)
Cannot allocate memory WARNING: Cannot run '/usr/bin/ntlm_auth' process." And "helperOpenServers:
Starting 1/50 'ext_wbinfo_group_acl' processes ipcCreate: fork: (12) Cannot allocate memory WARNING: Cannot
run '/usr/lib64/squid/ext_wbinfo_group_acl' process. " - it seemed odd to me that a squid -k rotate
would either restart/stop/start helpers. Shouldn't a squid -k rotate leave helpers alone when it's just
instructing squid to rotate the logs?
The helpers are logging to cache.log via stderr. They need to be restarted to
connect to the new cache.log once it has been rotated.
What does the mgr:ntlmauthenticators report show about the NTLM helpers when
this is going on?
Okay this looks like you are hitting bug 3643. Where Safari (and any
other clients behaving the same) could cause the helpers to get stuck in
R / Reserved state.
This is fixed in 3.4, but unfortuately the fix requires a few background
design changes so is not in 3.3. Are you able to use the latest daily
snapshot of 3.4 (labeled r12997 or later).
Amos
