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