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

Re: Mount namespaces

On Mon, 2016-08-22 at 13:26 +0100, Wookey wrote:
> 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.

Mount namespaces are now quite an old feature; they were introduced in
Linux 2.4.19.  However, systemd changes the default propagation mode
for mount namespaces to "shared", i.e. new mounts are propagated to
peer namespaces by default.  The section "Shared Subtrees" in
mount_namespaces(7) explains the different propagation modes and the
reasons for wanting propagation by default.
Unfortunately, some applications that manipulate mount namespaces
expect the old default, "private" (no propagation) but do not
explicitly request it.

> 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 don't know what's going on there.

> 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?

Perhaps its unit file includes MountFlags=private.


Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: