[systemd-devel] mount units and automatic (un)mounts

[Alad Wenter]

Andrei Borzenkov wrote:
> 15.07.2016 18:16, Alad Wenter пишет:
>> Hi,
>>
>> When a device is mounted, a matching mount unit is created per
>> systemd.mount(5):
>>
>> Mount points created at runtime (independently of unit files or
>>        /etc/fstab) will be monitored by systemd and appear like any other
>>        mount unit in systemd. See /proc/self/mountinfo description in
>>        proc(5).
>>
>> If the device is removed while the mount is still active, systemd
>> unmounts the stale mount. However, if umount exits with a non-zero
>> status—for example, when the mount is still accessed and the drive
>> connection is flakey—the unit enters a failed state:
>>
>> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
>> process exited, code=exited status=32
> Please do not make things more confusing then they are already. You do
> not speak about in-memory instantiated mount units, you speak about
> static on disk mount units (may be generated from /etc/fstab but do not
> really need to).
>
>> Jul 12 17:00:34 thinkpad systemd[1]: Failed unmounting /mnt/toshiba-usb.
>> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Unit is
>> bound to inactive unit dev-sdc1.device. Stopping, too.
>> Jul 12 17:00:34 thinkpad systemd[1]: Unmounting /mnt/toshiba-usb...
>> Jul 12 17:00:34 thinkpad umount[6341]: umount: /mnt/toshiba-usb: target
>> is busy
>> Jul 12 17:00:34 thinkpad umount[6341]:         (In some cases useful
>> info about processes that
>> Jul 12 17:00:34 thinkpad umount[6341]:          use the device is found
>> by lsof(8) or fuser(1).)
>> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
>> process exited, code=exited status=32
>>
>> On subsequent mounts, the device may be unmounted immediately unless
> This is caused not by failed (u)mount but by dis- and re-appearing
> device, when it emerges under different name.
>
>> "systemctl reset-failed" is issued (note that appending the .mount unit
>> doesn't work in this case, giving a "Unit mnt-transcend\x2dsdhc.mount is
>> not loaded" error).
>>
> So how exactly do you call it?
% sudo systemctl reset-failed mnt-transcend\x2dsdhc.mount
Failed to reset failed state of unit mnt-transcendx2dsdhc.mount: Unit
mnt-transcendx2dsdhc.mount is not loaded.

Being now aware of the distinction between in-memory and static units, I
assume this is due to mnt-transcend\x2dsdhc.mount being in-memory? The
reset-failed command works as expected with .mount units which are on disk.
>
>> A few possibly related bug reports:
>>
>> https://github.com/systemd/systemd/issues/2475
>> https://github.com/systemd/systemd/issues/1741
>> https://github.com/systemd/systemd/issues/1656
>>
>> My attempt at a workaround is disabling systemd-fstab-generator per
>> systemd.generator(7), and creating a `mount -a` service which mounts
>> file systems at boot.
>>
>> [Unit]
>> Description=Mount local filesystems
>> Documentation=man:mount(8) man:systemd.mount(5) man:bootup(7)
>> DefaultDependencies=No
>> After=local-fs-pre.target
>>
>> [Service]
>> Type=oneshot
>> RemainAfterExit=yes
>> ExecStart=/bin/mount -a -t nocifs,nosmbfs,nonfs
>>
>> [Install]
>> WantedBy=local-fs.target
>>
>> However, according to the systemd.mount(5), .mount units will be
>> generated either way. Oddly enough, when using the above service they
>> don't seem to cause automatic mounts/unmounts.
>>
> Because in this case you do not have static mount units, and for
> transient mount units (created from external mount event) things were
> partially fixed by not requiring existing device.
Could you give a pointer on what release this was partially fixed in? In
the NEWS file, I only found a mention to systemd 219 which introduced
unmounting of unavailable devices.
>> How can this be the case? Is a better approach possible?
>>
> Current approach is fundamentally incompatible with manual mounting. At
> the very least, manual mount (outside systemd) must override any static
> information systemd may have. I.e. if systemd has foo.mount for device
> /dev/foo and sysadmin manually calls "mount /dev/bar /foo", systemd has
> no business to interfere and unmount.
Thanks for the clarifications,

Alad