Well.. squid really likes to have a /dev/null there when running in daemon
mode (the default unless -N is specified) and when starting helper
processes.
As you get errors on opening /dev/null there seems to be something badly
wrong with your jail.
In daemon mode (no -N option) there are two processes, one Squid, one
monitoring daemon to keep it running in case of problems.
I have not tested the chroot_dir facility on Solaris, only Linux, but it
is pretty basic and I see no reason why it should not work on Solaris
given the correct files and devices in the jail.. "all" the directive does
is to chroot() to the specified directory (and fully drop root privs)
after parsing and validating the configuraiton file but before doing
anything else.
If you are using a manual chroot(1m) then Squid should basically work if
you can get a shell and telnet running in the chroot jail.. (delete them
after testing)
I don't know about truss on Solaris, but the Linux equivalence "strace"
can trace a program from the start (starting by loading the program,
dynamic loader etc...)
Regards
Henrik Nordstr�m
Squid Developer
On Monday 07 January 2002 10.35, adam morley wrote:
> 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.
-- MARA Systems AB, Giving you basic free Squid support Customized solutions, packaged solutions and priority support available on requestReceived on Mon Jan 07 2002 - 03:13:20 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:39 MST