[Bug 902612] New: systemd automounts manually umounted devices again
http://bugzilla.opensuse.org/show_bug.cgi?id=902612 Bug ID: 902612 Summary: systemd automounts manually umounted devices again Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: sweet_f_a@gmx.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Just noticed that systemd automatically mounts devices again allthough I've manually umounted them. Here is what I did $ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered) ## umount and disable that lvm device $ umount /mnt/local $ lvchange -an vg0/local systemd[1]: Stopping File System Check on /dev/vg0/local... systemd[1]: Stopped File System Check on /dev/vg0/local. ## enable device again $ lvchange -ay vg0/local systemd[1]: Found device /dev/mapper/vg0-local. systemd[1]: Found device /dev/disk/by-uuid/177a415d-174d-4c30-8897-5502c0419ef8. systemd[1]: Found device /dev/disk/by-id/dm-uuid-LVM-uF33oY4c9yu00EPAP42a8A2XZCfQTRRPGfiv0cNZRwPKIRJnOboscsc1z60174dd. systemd[1]: Found device /dev/disk/by-id/dm-name-vg0-local. systemd[1]: Found device /dev/dm-0. systemd[1]: Found device /sys/devices/virtual/block/dm-0. systemd[1]: Starting File System Check on /dev/vg0/local... systemd-fsck[6386]: /dev/mapper/vg0-local: clean, 648240/3276800 files, 9308645/13107200 blocks systemd[1]: Started File System Check on /dev/vg0/local. systemd[1]: Mounting /mnt/local... kernel: [ 5542.579700] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr systemd[1]: Mounted /mnt/local. $ mount | grep local /dev/mapper/vg0-local on /mnt/local type ext4 (rw,relatime,data=ordered) So what kind of automount is this? How to disable this odd behaviour? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
Bernhard Wiedemann
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
Per Jessen
(In reply to Ruediger Meier from comment #10)
As a summary, I'm open for suggestions stopping the automount during device maintenance or for whatever special purpose you have.
If 'umount' can no longer be relied upon to unmount a device until it is explicitly mounted or the system is rebooted, that IS a serious issue and it needs fixing. Surely it cannot be the desired behaviour? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
--- Comment #30 from Per Jessen
Hmmm .. IMHO there should exactly *one* /etc/fstab and all tools including systemd have to use *exactly* this one.
IMHO it should be possible for a system admin to stop udevd service before perform surgery on the open hard aka the active device. AFAIK there is a control option within the man:udevadm(8) which includes -s/-S (or --stop-exec-queue/--start-exec-queue).
IMHO a System Adminstratos should be able to do
umount /mnt/local udevadm control --stop-exec-queue lvchange -an vg0/local lvchange -ay vg0/local [...] udevadm control --start-exec-queue
... this should solve the problem, that is udevd will still queue events but not handle them. IMHO this should avoid the automatic mount.
I guess it would, but having to add an extra step instead of just the single "umount", is destined for disaster. People have to be able to rely on "umount" causing the device to be unmounted and remain unmounted. IMNSHO. Imagine if the behaviour of "rm" was changed in the same way? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
--- Comment #32 from Andrei Borzenkov
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
--- Comment #33 from Stanislav Brabec
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
--- Comment #34 from Andrei Borzenkov
Thomas Blume (comment 31):
I can imagine
What problems are you trying to solve? (In reply to Andrei Borzenkov from comment #32)
zypper ar obs://home:arvidjaar:bnc:902612:13.1/standard zypper ar obs://home:arvidjaar:bnc:902612:13.2/standard
It could take some time for OBS to publish them
Build is finished. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
--- Comment #37 from Stanislav Brabec
Thomas Blume (comment 31):
I can imagine
What problems are you trying to solve?
Current fstab situation: - All "auto" (the default) mounts are handled by systemd. - All "auto" (the default) mounts are handled by mount -a. But systemd-mounted volumes cannot be permanently unmounted by umount. Proposed fstab situation: Each fstab entry will clearly states, whether the volume is handled by systemd or not. This is just one of possible solutions for the reported problem. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
Andrei Borzenkov
(In reply to Per Jessen from comment #30)
AFAIK and AFAICS after a umount a device remains unmounted. Only if you causing a kernel event (which umount/mount do not) accordingly with such a device the systemd will mount if the device is part of the /etc/fstab without noauto option set.
Even this does not happen consistently. Sometimes it will not mount; sometimes it will.
(In reply to Andrei Borzenkov from comment #32)
What exactly, beside disabling a major feature[1], should the patch
systemd-do-not-add-Wants-to-device-for-mount-and-swap.patch
do here? Does this mean that we now have readd the `mount -a' and also a `swapon -a' within an own service unit?
No. You misunderstand how mounting on boot works. Did you actually try my build? Was any filesystem missing?
[1] For all here in this bug: Please could we have a real solution which will be acceptable for upstream as well? It is a matter of fact that mounting devices from /etc/fstab is event driven
It is not. Filesystems from /etc/fstab are added as Requires dependencies to local-fs.target. On boot local-fs.target gets started which triggers start of mount units for filesystems from /etc/fstab. Only on this stage is Wants added to device. So it is exactly opposite - this stupid dependency is added *because* filesystem gets pulled in by some other unit, not filesystem gets mounted because this dependency exists. (In reply to Thomas Blume from comment #36)
2. make sure that systemd only automounts an fstab entry at the first device
Yes. This was always the semantic of /etc/fstab and there is no reason to change it incompatibly. For anyone wanting something different there are native mount units - you are free to express any fancy dependency there. If you want automount on device appearance - just add Wants to device unit. Explicitly. The main problem of current situation is not that it does something stupid by default - but that there is no way to disable this without losing major functionality.
The most user friendly one, is probably option 2, as it combines the event driven behaviour of systemd, and the oneshot behaviour of SystemV mount. Not really sure how to implement this, though.
My patch does it :) If you accept that it had never been event driven in the first place ... (In reply to Stanislav Brabec from comment #37)
What problems are you trying to solve?
Current fstab situation:
- All "auto" (the default) mounts are handled by systemd. - All "auto" (the default) mounts are handled by mount -a.
Sorry? Where is "mount -a" in boot sequence? Could you elaborate what you mean? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
--- Comment #39 from Stanislav Brabec
What problems are you trying to solve? Current fstab situation:
- All "auto" (the default) mounts are handled by systemd. - All "auto" (the default) mounts are handled by mount -a.
Sorry? Where is "mount -a" in boot sequence? Could you elaborate what you mean?
No. Just two tools that both try to handle "auto" mounts. One tries to mount it every time it appears (the systemd called on boot), the another one does one-time mount (mount, currently not called in boot sequence). Both tools are completely different solutions, and combining mount done by one and umount done by the second is not a safe way to do things. However both tools work on top of the same data set: /etc/fstab. I proposed to keep a single fstab, but add a special flag for all volumes handled by systemd. Systemd will not touch other volumes, and mount/umount will be aware that volumes with "systemd" flag need a special care. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
http://bugzilla.opensuse.org/show_bug.cgi?id=902612#c46
Franck Bui
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
http://bugzilla.opensuse.org/show_bug.cgi?id=902612#c47
Ruediger Meier
13.1 has reached EOL and is not supported anymore.
Feel free to open a new bug report if this still can be reproduced on a newer/supported distro such as Leap or Tumbleweed.
Thanks.
Of course it is still the same misbehavior, just validated for Leap 42.2. Very annoying. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612
http://bugzilla.opensuse.org/show_bug.cgi?id=902612#c48
Franck Bui
participants (1)
-
bugzilla_noreply＠novell.com