chrooting bind (the sequel)

[Kevin Darcy]

This looks like a bug in the threading library. Are you sure you have the same version of
the threading library both in and out of the chroot jail? Maybe the version you have
outside of the chroot jail (presumably in /usr/lib) is a bad one -- that's the version
named will use when chroot()'ing via "-t".


- Kevin

Christopher L. Barnard wrote:

> After fighting other fires, I am finally coming back to the issue of
> chroot-ing bind9 on Solaris 7 and 8 machines.
>
> I am already using the -u flag to run named as a non-root user, btw.
>
> One box I have chrooted using the OS chroot().  However, as several people
> pointed out, this necessitates keeping the libraries, binaries, devices,
> etc. current when the system is patched.
>
> I would like to chroot another box using the -t option of named.  I have a
> jail for named (/opt1/named.jail).  This jail directory has one subdirectory,
> /etc.  The etc directory then has one subdirectory that has all of the named
> configuration files.  The reason for these directories-in-directories is to
> mimic the layout of the non-chooted environment, which means the named.conf
> file is the same.  The problem:  when I execute
>
> /usr/local/sbin/named -u named -t /opt1/named.jail
>
> I get the error
> libthread panic: _sys_thread_create():alloc_thread returns 0 (no mem) (PID: 20010 LWP 1)
> stacktrace:
>         ff2579d0
>         6384c
>         47d6c
>         47f80
>         41088
>         0
> I have no idea what this panic means.
>
> the process named is in the process table, but according to the named logs
> and the system messages it never starts up.  The named process in the process
> list has to be killed with a -9, btw.