[clug] init.d for chroot

steve jenkin sjenkin at canb.auug.org.au
Fri Jul 14 04:31:07 UTC 2017

> On 12 Jul 2017, at 14:44, jm via linux <linux at lists.samba.org> wrote:
> Due to a package clash between one version of a program used to support
> other hosts that has to run on this host and the one used to support
> this host I've set up a chrooted environment. I'm to the stage where I'm
> trying to start it from an init.d script - This is a CentOS 6 (yes, 6)
> box. The init.d script needs to start supervisord within the chroot
> which will then watch over the few processes that need to run chrooted
> for this to work. The problem here is that I can't work out how to get
> the pid of the chrooted process to record it later for the stop part of
> the script. I can't kill it be name via killproc as there is already a
> supervisord process on the host.
> The the key parts of the script in skeleton form at the moment is,
> start () {
>  echo -n $"Starting chrootname supervisord: "
>  chroot /chrootpath /usr/bin/supervisord -c /etc/supervisord.conf
>  # Store pid of supervisord
>  RETVAL=$?
>  echo
>  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/chrootname-supervisord
> }
> stop () {
>  echo -n $"Stopping chrootenv supervisord: "
>  # Get stored pid and kill process
> }
> Does anyone have any experience with scripts like this or thoughts on
> how to do this? I'm currently think about putting a wrapper around
> supervisor that runs in the chroot env to record the pid in the chroot env.
> Jeff.


I would’ve hoped “localhost” worked with a remote monitoring environment, allowing you to avoid duplicated environments entirely.
As you say, different incompatible package versions have left you with a difficult problem.

chroot(2) was first implemented before /proc & /sys were added into Linux.
Process control was done solely via syscalls and chroot’s did not provide ‘process control' isolation for safe sandboxes.
Networking, BSD sockets, also came after chroot() and chroot’ed processes weren’t controlled there either. 

The FreeBSD jail(2), circa 2000, was an attempt to provide strong process isolation / sandboxes.

Linux containers, ending with the common LXC environment supported in the kernel, addressed these weaknesses, creating good ‘sandbox’ environments, as leveraged by Docker and others.
Because ‘containers’ start with a chroot(), they need to create a full executable environment: why they need a mini-distribution installed in each.

Creating a ‘simple’ working chroot environment requires a deal of work to make ‘enough’ of an running environment available.

For example: If you haven’t mounted /proc into the chroot environment, nothing related to processes will work.
If you haven’t created & populated /bin and /lib, you won’t be able to perform many actions, including opening new dynamic libraries.
Not sure if the loader, needed to fork a process IIRC, will fail or not - there is no path to the userland component.

If you’re having trouble returning a PID from a chroot’ed script, it may be because you need to create more of an environment within the chroot dirs.

I’d include a ‘bind’ mount of /var/run for supervisord to store the PID - but you’d need two versions (names) of that file, one for the local version and another for the remote.

I’m not sure of the process control isolation semantics applying to chroot() using /proc.
I think they are spawned under a new ‘process group’, making them able to control only processes within that ‘group’ (e.g. kill).
But I’d expect main system processes (not chrooted), would be able to control all processes, including with the chroot, as per normal semantics.

Some “how to’s” on setting up chroot() environments.
Perhaps there’s something you need to add to the chroot environment you’ve created for the older (?) package.


Random older page:

How to build a chroot jail environment for CentOS

[worth reading even for CentOS users, lists many steps, including all the ‘mount’ commands needed]


Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin

More information about the linux mailing list