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?

> 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.

> 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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to