[squid-users] [RESOLVED] RE: [squid-users] WORKERS: Any compile option to enable? commBind: Cannot bind socket FD 13 to [::]: (2) No such file or directory

----------------------------------------
> Date: Sun, 12 Jun 2011 21:23:44 +1200
> From: squid3_at_treenet.co.nz
> To: bodycare_5_at_live.com
> CC: squid-users_at_squid-cache.org; squid-dev_at_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.
 
Oh jesus! Apparently --prefix was added to the end of --target because of end-of-line space!
 
strings squid|grep bindir:
<snip> '--target=x86_64-redhat-linux-gnu--prefix=/squid' '--bindir=/squid' '--sbindir=/squid' <snip>
 
 
./configure \
--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu\
--prefix=/$SQUID --bindir=/$SQUID --sbindir=/$SQUID --libexecdir=/$SQUID --datadir=/$SQUID --sysconfdir=/$SQUID \
 
Thanks Amos!
 
Jenny
 
 
 
 
 
 
 
 

>
> 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.
>
>
> 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.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE9 or 3.1.12
> Beta testers wanted for 3.2.0.8 and 3.1.12.2
Received on Mon Jun 13 2011 - 09:07:10 MDT