Bug#798965: closed by Michael Biebl <biebl at debian.org> (Re: Bug#798965: systemd: Unit mnt.mount entered failed state)

[Frank Heckenbach]

> > - Remembering what little I know about systemd, I did
> >   "systemctl daemon-reload", and indeed this seemed to fix the
> >   problem.
> 
> Correct, you need to run daemon-reload after changes to /etc/fstab.
> Using inotify on configuration files was rejected upstream since you
> don't know, when the config files are in a consistent state.

But it breaks previous long-standing behaviour of unrelated programs!

For people who like systemd, this may be fine. But people who don't
care about systemd don't want to be forced to cater about systemd's
whims. (Note, in my situation, the only time when it's needed to
know that fstab is in a consistent state is when doing the mount,
and that's up to the user (me) to ensure when doing the mount
command, as has always been. After that, none of my actions should
have any relation to mounts at all, so fstab is irrelevant. If
systemd wants to deal with mounts without my request, it's its own
problem, not mine, how to do so correctly.)

FWIW, so far I've been one of the few people on the neutral side of
the pro- and anti-systemd wars. Things like this are helping pushing
me to the anti side!

So, is there at least a way to tell systemd to keep its fingers out
of my mounts? Again, simply unmounting what I've mounted just
because it can't understand what's going on is not acceptable.