chrooting bind (the sequel)

[Kevin Darcy]

Upon further reflection, it may not be so much a case of the threading library having a bug,
_per_se_, as it being incompatible with whatever version of the threading library you
compiled against...


- Kevin

Kevin Darcy wrote:

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