----------------------------------------
> Date: Sun, 12 Jun 2011 21:23:44 +1200
> From: squ...@treenet.co.nz
> To: bodycar...@live.com
> CC: squid-users@squid-cache.org; squid-...@squid-cache.org
> Subject: Re: [squid-users] WORKERS: Any compile option to enable? commBind:
> Cannot bind socket FD 13 to [::]: (2) No such file or directory
>
> On 12/06/11 20:21, Jenny Lee wrote:
> >
> >>>> Subject: Re: [squid-users] WORKERS: Any compile option to enable?
> >>>> commBind: Cannot bind socket FD 13 to [::]: (2) No such file or directory
> >>>>
> >>>> On 12/06/11 16:17, Jenny Lee wrote:
> >>>>>
> >>>>> I can't get the workers work. They are started fine. However I get:
> >>>>>
> >>>>> kid1| commBind: Cannot bind socket FD 13 to [::]: (2) No such file or
> >>>>> directory
> >>>>> kid2| commBind: Cannot bind socket FD 13 to [::]: (2) No such file or
> >>>>> directory
> >>>>> kid3| commBind: Cannot bind socket FD 9 to [::]: (2) No such file or
> >>>>> directory
> >>>>>
> >>>>> Is there a compile option to enable/disable workers that I am missing?
> >>>>
> >>>> I can't seem to replicate that here. More details are needed about what
> >>>> FD 13 and FD 9 were being used for please.
> >>>
> >>>
> >>> 649 kid1| comm.cc(2507) comm_open_uds: Attempt open socket for:
> >>> /usr/local/squid/var/run/squid-1.ipc
> >>> 649 kid1| comm.cc(2525) comm_open_uds: Opened UDS FD 13 : family=1,
> >>> type=2, protocol=0
> >>> 649 kid1| comm.cc(2528) comm_open_uds: FD 13 is a new socket
> >>> 649 kid1| commBind: Cannot bind socket FD 13 to [::]: (2) No such file or
> >>> directory
> >>>
> >>> symlinking /usr/local/squid/var/run to /squid fixed the problem. I have
> >>> everything in /squid.
> >>
> >> Aha, then you probably need to use ./configure --prefix=/squid
> >>
> >> That should make the socket /squid/var/run/squid-1.ipc
> >
> > Trimmed for brevity:
> >
> > strings /squid/squid|grep '^\/'
> > /lib64/ld-linux-x86-64.so.2
> > /etc/resolv.conf
> > /squid/errors/templates
> > /dev/tty
> > /dev/null
> > /squid/squid.conf
> > /usr/local/squid/var/run/coordinator.ipc
> > /usr/local/squid/var/run/squid
>
> Strange those last two are UNIX sockets with address:
> $(prefix)"/var/run/coordinator.ipc"
> $(prefix)"/var/run/squid"
>
> and yet the errors and squid.conf picked up the prefix right.
>
> Notice how that last one has the same name as the squid binary? Yet is a
> unix socket name. Strange things can be expected when you execute a
> socket or try to write a data stream over a binary.
I think that is not a socket. But that is a directory where socket will reside.
Most daemons now are moving to their own directories under /var/run due to
selinux.
squid-1.ipc and squid-2.ipc is created inside that direcotory with workers. How
to find out what exactly it is from the binary?
It indeed sounds alarming. But then again, I didn't face a bug in this setup
that was not reproducible with stock install over the years.
But now... if i indeed symlink /usr/local/squid/var/run to /squid... that last
entry will point straight to squid binary.
>> I suggest you let the installer use the standard FS hierarchy locations
> for these special things. You can use --prefix to setup a chroot folder
> (/squid) where a duplicate of the required layout will be created inside.
I can't do chroot because squid interfaces with other stuff or some other stuff
interfaces with squid.
I am having /squid setup 9 years now.
> Meanwhile I'm not sure exactly how the /usr/local/squid/var/run/ got
> into the binary. Maybe junk from a previous build.
> Try erasing src/ipc/Makefile src/ipc/Makefile.in and src/ip/Port.o
> then running ./configure and make again.
I run configure from a script and it erases squid tree and unpacks the tarball
at each compile (so that I would not face issues like this).
Thanks!
Jenny
