Lazy unmount root jail drives

Question

I have created a root jail containing rpm and yum (centos 7.5) to install some software on the original system.

Workflow

• Mount sys, proc, dev to the root jail
• Mount root of the original system "/" to the jail. This is important since I use the root jail to actually install software on the base system
• Mount sys, proc, dev of the original system inside the root of the original system in the rootJail e.g. mount /proc /rootJail/originalRoot/proc which is needed for some software being installed
• enter root jail, install software, exit root jail
• unmount sys, proc, dev from the root jail
• umount sys, proc, dev from the original system inside the root jail
• unmount the original systems root from the root jail (this is where it fails)

umount: /rootJail/originalRoot: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))

So I can basically unmount everything except the root of the original system itself. I need to to that in order to remove the root jail which is mandatory.

The Problem is, that lots of processes being started after installation of the software inside the root jail. That's why it tells me that the target is busy. Killing all these is processes is not possible since this also kills the system. It seems like these processes are bound to the rootJail instead of the real System even when the installation path is correct. Also, after a reboot everything is working perfectly (Worst case: remove the folder here)

I already tried to do a lazy unmount which basically works. I can remove the rootJail and it does not seem to harm the original system which was mounted inside

My question is: is this safe to do? or are there any other solutions of how to unmount that folder?

Answer 1

So you seem to want these processes to keep running indefinitely, i.e. they are service processes - which have been started inside the nested chroot environment. This rather suggests that you are spawning a service process from your shell, instead of from systemd.

In general, this is bad and you will want to avoid it.

CentOS 7 uses systemd, running as PID 1 and managing system services. Obviously the PID 1 of the main system does not run inside your chroot. Normally, when you request the start of a system service process, it is forked off from PID 1 to provide a clean environment (customized according to the relevant .service unit file). (This includes legacy sysvinit scripts. They are imported into automatically-generated .service files).

(To illustrate this further: it is technically possible to run a chroot where you bind-mount in a socket to communicate with systemd, and use commands inside the chroot to manipulate the services of the host system).

The problem isn't just that your approach loses the benefits of systemd. It means you confuse the systemd service, if there is one for this daemon. For example, the service might show as not started (service foo status). If you later try to service foo restart... systemd will not know there is a daemon to stop, and it will try to start a second instance of the daemon instead. This is a bit confusing to debug! Often you will get a nice immediate error about not being able to start your web server because there's already another program listening on TCP port 80 :), but in other cases you could end up with two different instances of a daemon that think they should be the only one, wreaking errors that take longer to notice.