[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 <bwiedemann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwiedemann@suse.com Assignee|bnc-team-screening@forge.pr |systemd-maintainers@suse.de |ovo.novell.com | --- Comment #1 from Bernhard Wiedemann <bwiedemann@suse.com> --- Could also be from udev detecting the newly available block-devs which are likely mentioned in /etc/fstab -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=902612 Per Jessen <per@computer.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |per@computer.org --- Comment #13 from Per Jessen <per@computer.org> --- (In reply to Thomas Blume from comment #12)
(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 <per@computer.org> --- (In reply to Dr. Werner Fink from comment #29)
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 <arvidjaar@gmail.com> --- I created packages for 13.1 and 13.2 which do not add dependency on swap and mount unit to device. 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 (right now only i586 is published). You can use "osc getbinaries" in the meantime. Please test if there are any issues (like mounts not present). There will be no difference for mount points without "nofail" - if device is not present before local-fs times out, system will go into emergency mode today anyway. Mount points with "nofail" will not be automounted if they were missing during boot. I do not see any issue with it - they are explicitly declared as optional. Of course it is still possible to easily restore current behavior by explicitly adding dev-xxx.conf.d snippet that adds Wants on mount unit to device. Which is exactly opposite to current situation where it is NOT possible to disable device dependency without sacrificing automount on boot. P.S. with systemd update rate I'm fine with maintaining these packages forever :) -- 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 #33 from Stanislav Brabec <sbrabec@suse.com> --- Thomas Blume (comment 31): I can imagine following solution (systemd + util-linux): "systemd-essential": This flag would be considered as: - taboo for util-linux. Only --force would allow to umount them. - mount source for systemd "systemd-optional": This flag would be considered as: - noauto for util-linux. umount will additionally warn: "Warning: You are unmounting a volume managed by systemd. Volume will be remounted whenever device re-appears, unless you call "service foo.mount stop". - mount source for systemd Untagged entries will be ignored by systemd, except (optional) mount-a.service. I can imagine that there will be only one flag instead of upper two: "systemd" or "systemd-managed". And I can imagine that it will have argument, e. g. "systemd=var.mount". -- 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 #34 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Stanislav Brabec from comment #33)
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 <sbrabec@suse.com> ---
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 <arvidjaar@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(arvidjaar@gmail.c | |om) | --- Comment #38 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Werner Fink from comment #35)
(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 <sbrabec@suse.com> ---
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 <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fbui@suse.com Resolution|--- |WONTFIX --- Comment #46 from Franck Bui <fbui@suse.com> --- 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. -- 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#c47 Ruediger Meier <sweet_f_a@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Component|Basesystem |Basesystem Version|Final |Leap 42.2 Resolution|WONTFIX |--- Product|openSUSE 13.1 |openSUSE Distribution --- Comment #47 from Ruediger Meier <sweet_f_a@gmx.de> --- (In reply to Franck Bui from comment #46)
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 <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WONTFIX --- Comment #48 from Franck Bui <fbui@suse.com> --- As far I understand this bug it's a design "feature" (or shortcoming if you prefer) of systemd. IOW you need to discuss this with upstream. As far as we (downstream) are concerned, we won't deviate from upstream as it's a major behavior change. Please report the issue over there if it's not already done. Closing. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com