---------------------------------------- > 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. 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
