On 29/08/2012 9:25 p.m., Nathan Hoad wrote:
Hi folks, I'm running Squid 3.2.1 with NTLM auth configured as follows: auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5- ntlmssp auth_param ntlm children 133 auth_param ntlm keep_alive off And I'm seeing an issue where internet access was not available until Squid was restarted. Some requests were being serviced, but most were not. ntlmauthenticator from the manager reported the following: (I've put it on pastebin because it's moderately large): http://pastebin.com/5cvCteeU
What I see in that report is 221 helpers all of which are locked/reserved by some client which is partway through an NTLM handshake.
Due to the way NTLM authentication works, once a helper is used by a client to start a NTLM handshake sequence it must be used for the remainder of the sequence. Squid locks helpers to a particular client connection while they are participating in that process. Once the clients complete the handshake or abort the TCP connections which are being authenticated those reserved helpers should be released.
If you think that is not happening we will need a debug ALL,9 cache.log trace to identify where the problem is.
Restarting Squid obviously closed the connections, and resolved the issue, but it's not really practical to keep restarting. This issue is not present in 3.1.9. Have there been any significant modifications between 3.1.9 and 3.2.1 that could have caused this?
You could say so. The entire auth subsystem was re-designed.
Or shall I file a bug report?
If you are sure it is incorrect handling of helers after NTLM completes or connections are aborted please do so. The other developers do not read this list and you will get better help if we can all consider the issue.
I'm more than happy to provide what additional information I can to help diagnose the issue. There are about 1500 machines running behind Squid, for what it's worth. Thanks, Nathan.
Amos
