On Thu, 15 Jun 2017, Andrei Borzenkov wrote:
14.06.2017 16:58, Andre Maasikas пишет:
systemd: Unit xx.mount is bound to inactive unit dev-mapper-xx.device.
Stopping, too.
systemd: Unmounting /mountpoint...
kernel: XFS (dm-22): Unmounting Filesystem
systemd: Unmounted /mountpoint.
systemd: Unit xxx.mount entered failed state.
(dev-mapper-xx being the old/removed device-mapper device)
Welcome to the club.
Finally using the second set of keywords reveals that I'm supposed to
#systemctl daemon-reload
whenever i edit fstab.
Seems like the fstab file is not always authoritative anymore and the
authoritative configuration
No, it is not.
As far as I know, it *is* if the mount utility is used directly, since it
just invokes the mount(2) syscall. systemd will track the new point just
as if any other program had created one. It shouldn't matter if systemd's
generated unit files are out-of-date.
What seems to be the problem here is:
systemd: Unit xx.mount is bound to inactive unit dev-mapper-xx.device.
Stopping, too.
I don't know enough about multipath devices or their management to know
what's going on there though.
Various configuration files are translated by systemd
generators into native units, afterwards these configuration files
become irrelevant. Which is pretty much clear, given that systemd was
created with a single task in mind - start services during system boot,
and so has no provision for run-time changes. It has workaround
(daemon-reload) but as you never know which generators exist (nor have
any way to discover it) you are bound to call this after editing near to
every file on your system ...
is kept god-knows elsewhere and these might not be in sync and depend on
god-knows what and if you don't know that it's now allowed to automatically
unmount a perfectly good working filesystem from under you without any
warning. A quick review of fstab header, man fstab, man mount etc. does
not reveal any information about this newish behavior. Also no commands
that got me to this point gave any errors or indication that this will be
happening.
It might be something else I did incorrectly or distribution specific (RHEL
7.2) or a bug already fixed. Most certainly I have not learned enough of
the the new ways of systemd (and selinux)
You did not do anything wrong and I do not see how it can really be
fixed. Note that even native units have exactly the same issue -
changing on-disk unit definition is not noticed by systemd until
daemon-reload (and then what is actually running may not match unit
definition anymore).
I'm pretty it should only be necessary to call daemon-reload before using
systemctl. It warns if any source files (unit files, dropins and anything
mentioned by SourcePath= in a unit) have been updated since the last
reload. The fstab generator should be using SourcePath=.
- Michael
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
