Re: [squid-users] squid_session problem

Eureka!

It appears that despite ipv6 being disabled on the Ubuntu Server OS
itself, it was still interfering with the helper somehow. All I had to
do was change the line in squid.conf that starts with
"external_acl_type" to read:

> external_acl_type session ipv4 ...

and all of a sudden, cache.log stopped displaying errors, and
everything started to work. It redirects properly now.

Thank you Amos for your time, and advice. If we ever meet in person,
remind me that I owe you a beer :)

Tal

On Thu, Jul 12, 2012 at 9:40 AM, Jack Black <secretagent101_at_gmail.com> wrote:
> I have no idea why, but all of a sudden, after reinstalling and
> reconfiguring squid 3.2.0.18 from scratch, my Ubuntu Server 12.04 64
> bit VM started working. I really did nothing special to get it to run
> - just the same as I've been doing. As soon as this happened, I
> quickly followed the same steps on my real Ubuntu Server 12.04, but
> there, it once again refused to work. The squid.conf file on the
> working VM and my production Ubuntu Server aren't just similar - they
> have the same md5 checksum. They are exactly the same.
>
> I tried the -d flag, but it had no effect on the level of detail found
> in cache.log. This is probably to be expected, considering I just
> spotted this line within the same log file:
>
> WARNING: Cannot run '/usr/local/squid/libexec/ext_session_acl' process.
>
> Here's the section around that line:
>
> 2012/07/12 09:02:20 kid1| Starting Squid Cache version 3.2.0.18 for
> x86_64-unknown-linux-gnu...
> 2012/07/12 09:02:20 kid1| Process ID 8871
> 2012/07/12 09:02:20 kid1| Process Roles: worker
> 2012/07/12 09:02:20 kid1| With 1024 file descriptors available
> 2012/07/12 09:02:20 kid1| Initializing IP Cache...
> 2012/07/12 09:02:20 kid1| DNS Socket created at [::], FD 8
> 2012/07/12 09:02:20 kid1| DNS Socket created at 0.0.0.0, FD 9
> 2012/07/12 09:02:20 kid1| Adding nameserver 205.233.109.40 from /etc/resolv.conf
> 2012/07/12 09:02:20 kid1| Adding nameserver 8.8.8.8 from /etc/resolv.conf
> 2012/07/12 09:02:20 kid1| helperOpenServers: Starting 1/1
> 'ext_session_acl' processes
> 2012/07/12 09:02:20 kid1| commBind: Cannot bind socket FD 10 to [::1]:
> (99) Cannot assign requested address
> 2012/07/12 09:02:20 kid1| commBind: Cannot bind socket FD 11 to [::1]:
> (99) Cannot assign requested address
> 2012/07/12 09:02:20 kid1| ipcCreate: Failed to create child FD.
> 2012/07/12 09:02:20 kid1| WARNING: Cannot run
> '/usr/local/squid/libexec/ext_session_acl' process.
> 2012/07/12 09:02:20 kid1| Logfile: opening log
> daemon:/usr/local/squid/var/logs/access.log
> 2012/07/12 09:02:20 kid1| Logfile Daemon: opening log
> /usr/local/squid/var/logs/access.log
> 2012/07/12 09:02:20 kid1| Store logging disabled
> 2012/07/12 09:02:20 kid1| Swap maxSize 0 + 262144 KB, estimated 20164 objects
>
> I tried changing the ownership of the ext_session_acl file to
> proxy:proxy, and even set its permissions to 777, but neither helped.
> It doesn't appear to be a permissions issue. Is there anything
> obviously wrong here that might indicate why ext_session_acl won't
> run? Like maybe the line that reads "ipcCreate: Failed to create child
> FD."? Or is that normal?
>
> Tal
>
> On Wed, Jul 11, 2012 at 7:12 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 12.07.2012 12:37, Jack Black wrote:
>>>
>>> I just tried the same squid configuration on Ubuntu Mini remix 11.04
>>> x64, and Ubuntu Desktop 12.04 x64 live (I didn't even bother
>>> installing it). They both work perfectly, just like CentOS. Whatever
>>> the problem is, it appears to be specific to Ubuntu 12.04 Server
>>> edition for some reason, which just happens to be the exact OS my
>>> production server (the one that needs to run squid) is running.
>>> There's got to be something that I'm missing...
>>>
>>
>> Since you have the helper from squid-3.2 built stick with that one. It has a
>> few important bug fixes and the -d flag operating.
>>
>> If you add -d to the helper command-line parameters in squid.conf it should
>> record in cache.log what is going on with each session lookup.
>>
>> I'm kind of suspicious that the helper is having problems in the background
>> that are not showing up.
>>
>> Also double-check that the squid.conf are completely identical between the
>> machines. Security in squid is default-closed so the expected behaviour with
>> a failing helper should be causing TCP_DENIED constantly to the client on
>> Ubuntu, not access to the Internet.
>>
>>
>> Amos
>>
Received on Thu Jul 12 2012 - 22:27:12 MDT