[systemd-devel] auto-unmount via BindsTo= is annoying

[Lennart Poettering]

On Sun, 05.04.15 08:38, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> When mount unit is not in cache, systemd creates *new* definition and
> sets BindsTo current device where filesystem is currently mounted.
> 
> If mount unit is present in cache, it already has some BindsTo. When
> systemd processes mountinfo it apparently neither removes old nor adds
> new BindsTo for new device. Which makes check kick in later.

Dependencies can only be added during runtime, never removed, as
systemd doesn't track where dependencies are created from, and we
don't really want to track that. The only way to remove deps is by
issuing "systemctl daemon-reload" or equivalent.

> a) it would be helpful if systemctl status/show could differentiate
> between unit loaded due to this systemctl call and unit having been
> loaded before. May be "--do-no-load" flag to systemctl or something
> like this.

systemctl doesn't load units. It's PID 1 that will do so implicitly
if a client references it. The client has no concept of loaded or
unloaded units, and can trigger loading only really as side affect of
accessing a unit that happens to be unloaded.

> b) when systemd finds out that What is different in mountinfo, it
> should remove BindsTo for old What. May be it should really simply
> always drop old mount unit (present in cache) and build new one from
> scratch. Or push old definition (to support stacked mounts).

Dropping deps is not supported, as mentioned. We need to find a
different solution for thi.

> c) The resulting unit should be clearly marked as different from
> definition on disk. I.e.

Internally we already track both settings.

> That is obviously wrong. What is mounted now comes *NOT*
> from /etc/fstab, and it should not be claiming it.

Well, it doesn't claim that. It just says that it loaded stuff from
/etc/fstab, but like with all units the state systemd tracks comes
from a veriety of sources...

I do see that this is a source of confusion so, but I am not too
convinced we should export such level of detail over the bus...

This is certainly an issue to think about, and I don't really have a
good answer right now what to do about this.

Note that this issue existed before the recent unmount logic change:
each time you mount and unmount a directory with a different source
device while it stays referenced we will collect a new dependency for
the backing device, and they will not be flushed out until the next
daemon reload... Previously it would only collect Wants= deps, and now
BindsTo=. In both cases this may bring breakage and confusion, though
with the later is certainly more visible...

Lennart

-- 
Lennart Poettering, Red Hat