[systemd-devel] magically disappearing filesystems

[Michael Chapman]

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