mjhjmtu

I have a (slightly complex) script which logs me into a chroot filesystem image for various purposes (not jail or security related, just needing different root environments for some things).

In some cases I want to have access to the "real" root filesystem while inside the chroot, and also to other filesystems mounted both before and after starting the chroot (notably network shares and USB disks).

The script does a recursive mount, which mostly works:

rmount() 
 mount --rbind "$1" "$2" && mount --make-rslave "$2"

urmount() 
 umount -R "$1"

mount -t proc proc "$TARGET/proc"
mount -t sysfs sysfs "$TARGET/sys"
mount --bind /dev "$TARGET/dev"
mount -t devpts devpts "$TARGET/dev/pts"
rmount / "$TARGET/host"
chroot "$TARGET" /bin/bash --login
urmount "$TARGET/host"
umount "$TARGET/dev/pts"
umount "$TARGET/dev"
umount "$TARGET/sys"
umount "$TARGET/proc"

(There's a few other pieces as well, but this is the mounting-related code. The rslave part is what allows umount -R to work, see https://unix.stackexchange.com/a/264488/78162.)

The problem is that sometimes (not sure what the trigger is, but it seems more likely to happen the longer things remain mounted) the root mount gets too recursive, and when running mount outside the chroot you start to see patterns like

/path/to/target/sys sysfs
/path/to/target/host/path/to/target/sys sysfs
/path/to/target/host/path/to/target/host/path/to/target/sys sysfs

etc (for all of the mounts, not just the sysfs mount). This eventually breaks the host system and all sorts of things start reporting "no space on device" errors. Once in this state the only thing that seems to resolve it is to reboot the host.

Possibly a contributing factor is that path/to/target itself specifies a path on a mounted filesystem different from where / is mounted.

Is there some way to resolve this and exclude following the root/host bind multiple times?