[squid-users] chroot'ed squid eats 100% cpu looking for /dev/null??!

Baffled, absolutely baffled i am. I've got the latest snapshot of squid (2.4.STABLE3 does the same thing) running inside a chroot. problem is, on startup, a second squid process starts (not sure why two start up? usually two start, then one quits, and the other keeps running, listening for connections) and this second process runs around looking for /dev/null and getting errors the whole time. unlinkd never starts (though it should, and would were it not for the chroot)

open("/dev/null", O_RDONLY) Err#6 ENXIO
open("/dev/null", O_RDONLY) Err#6 ENXIO

is what a truss of the process shows. sadly, it starts doing this so fast, i don't have time to truss it (this is solaris 8 btw) and find out what its doing.

   proxy 7738 7735 94 01:15:43 ? 1:08 (squid) -D
   proxy 7735 7733 1 01:15:43 ? 0:01 (squid) -D
    root 7733 1 0 01:15:43 ? 0:00 /opt/GMIsquid/bin/squid -D

the last one is the original starting process, the second one is what the first one forks to (i'm guessing) as it also stats the whole cache dir. then the first squid starts after its done stat'ing and gives the open() messages above. (you probably ask: why the -D? well, initially i had some issues with the name service cache under solaris, it was an easy way to get the thing started....yes, it does do hostname lookups right, its just when its starting its looking for /etc/.name_service_door or something like that.....fixes itself when it gets into the chroot and doesn't know about nscd anymore.)

the working dir for the first (squid) is the cwd of the shell which launches it. the same is true for the original starting process (run initially by root). the second (squid) process's working directory is the chroot.

/dev/null exists under the normal system (as expected) and /dev/null exists under the chroot. their major and minor numbers are the same, and they are both world mode 666, character devices (effectively, they match)

the files in the chroot are listed below:

# find . -print|grep -v \.\/squid
.
./dev <---- all devices match the major/minor numbers
./dev/conslog
./dev/log
./dev/msglog
./dev/null
./dev/sysmsg
./dev/tcp
./dev/udp
./dev/zero
./etc
./etc/group
./etc/init.d
./etc/nsswitch.conf
./etc/opt
./etc/opt/GMIsquid <---- --sysconfdir in configure (configuration files)
./etc/passwd
./etc/rc2.d
./etc/rc2.d/K89squid
./etc/rc3.d
./etc/rc3.d/S89squid
./etc/resolv.conf
./opt
./opt/GMIsquid <--- --prefix in configure
./squid <---- where cache files reside.
---omitted cache dirs---
./usr
./usr/lib
./usr/lib/ld.so.1
./usr/lib/libc.so.1
./usr/lib/libcrypt_i.so.1
./usr/lib/libdl.so.1
./usr/lib/libgen.so.1
./usr/lib/libm.so.1
./usr/lib/libmp.so.2
./usr/lib/libnsl.so.1
./usr/lib/libresolv.so.2
./usr/lib/libsocket.so.1
./usr/lib/locale <---- locale specific data
./usr/lib/nss_dns.so.1
./usr/lib/nss_files.so.1
./usr/platform <---- processor specific libraries
./usr/share <---- timezone info
./var
./var/opt
./var/opt/GMIsquid <---- --localstatedir in configure, used to store logs

this all sits in /export/proxy/jail with anal permissions and such, with $JAIL/etc/opt/GMIsquid, $JAIL/opt/GMIsquid loopback read only mounted and $JAIL/squid, $JAIL/var/opt/GMIsquid loopback read/write mounted.

so now my question: what am i missing? i'm guessing its something obvious and rather inane.....or is it possible that the second (squid) process that starts and looks for /dev/null wants to be in the chroot but doesn't get put there?

one more thing: i compiled this on one machine, tested it, it works fine. now i move it to this machine, and it doesn't. same os release (solaris 8 4/01) with the same recommended patch cluster. and the old version of squid that ran on here (2.4.STABLE1) was built using the same procedure, so i don't think it has anything to do with this.....but i'm not sure.

when run w/o the chroot set, squid works fine.

i'm wondering if you folks could make squid's chroot work how one would chroot apache:

chroot <dir> <binary>

seems like that would be much simpiler than having to put it in the config file and not be able to truss the execution (save for the initial process as root). but you probably thought of this, and do it this way for some reason.

thanks in advance,
adam
Received on Mon Jan 07 2002 - 02:36:23 MST