[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Mount namespaces

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?

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: Digital signature

Reply to: