I recently noticed that schroot could no longer tidy up chroots it had finished with. Much investigation with the help of debian Bug #749897 revealed that there is a problem with the combination of schroot, systemd and demons that use the 'private mount namespace' feature. (PrivateTmp=yes in the systemd unit definition).
If the system has any daemons that use this feature (e.g cups, colord, rtkit-daemon), then mount can no longer unmount at the end when tidying up the chroot. The daemons are nothing to do with the chroots - they are running in the main machine, but because of this namespace feature umount no longer works the way it used to. You get EBUSY on attempting to unmount. I'm bringing to this to debian devel as this is a major regression and I really don't understand how this new namespace thing is expected to work. Why does the use of this featuer confuse umount? Shouldn umount know about the namespaces and DTRT? Why can't it tell that these daemons are nothing to do with the chroots that are being cleaned-up? I'm fine with shiny new features, that I presume are useful for something (containers?), but it seems to me that they shouldn't be breaking longstanding behaviour, like the ability to unmount bind-mounts in a chroot. Currently anyone wanting to clean up an schroot chroot on a machine runing systemd, has to shut down the unrelated daemons: cups, colord and rtkit first, tidy the chroot and then restart them. This seems like madness, and cannot be how this was intended to work. So, where is the right place to discuss this? How exactly is this expected to work? Oh, and why does kdevtmpfs appear in the list of daemons with a private mount namespace, but it _doesn't_ need to be stopped to do the unmount? What is special about that one? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: Digital signature
