---------------------------------------- > Date: Sun, 12 Jun 2011 21:23:44 +1200 > From: squid3@xxxxxxxxxxxxx > To: bodycare_5@xxxxxxxx > CC: squid-users@xxxxxxxxxxxxxxx; squid-dev@xxxxxxxxxxxxxxx > Subject: Re: 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: 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
