Launchpad has imported 14 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1312011.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2016-02-25T14:04:19+00:00 Peter wrote: This rule may be problematic: SUBSYSTEM=="block", KERNEL!="ram*", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0" The "SYSTEMD_READY=0" will cause automatic unmount of mountpoint that is on top of such DM device. It's even more problematic if this is used with multipath which sets DM_UDEV_DISABLE_OTHER_RULES_FLAG in case we have a CHANGE event that comes after DM multipath device reload when one of the paths is down or up (see also bug #1310022). Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/0 ------------------------------------------------------------------------ On 2016-02-25T19:01:04+00:00 Ryan wrote: (In reply to Peter Rajnoha from comment #0) > This rule may be problematic: > > SUBSYSTEM=="block", KERNEL!="ram*", > ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0" > > The "SYSTEMD_READY=0" will cause automatic unmount of mountpoint that is on > top of such DM device. It's even more problematic if this is used with > multipath which sets DM_UDEV_DISABLE_OTHER_RULES_FLAG in case we have a > CHANGE event that comes after DM multipath device reload when one of the > paths is down or up (see also bug #1310022). Hi Peter. Glad to hear that this has been identified as a problem. Obviously I wouldn't normally edit /usr/lib/udev/rules.d/*.rules files (I know changes will be reverted on update of systemd; perhaps it works like systemd unit files and I could put an override file of the same name in /etc/udev/rules.d?) but if I comment out that rule in 99-systemd.rules, is it sufficient to run `udevadm control --reload` to avoid being bitten by this issue? Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/1 ------------------------------------------------------------------------ On 2016-02-26T07:58:08+00:00 Peter wrote: (In reply to Ryan Sawhill from comment #1) > Hi Peter. Glad to hear that this has been identified as a problem. Obviously > I wouldn't normally edit /usr/lib/udev/rules.d/*.rules files (I know changes > will be reverted on update of systemd; perhaps it works like systemd unit > files and I could put an override file of the same name in > /etc/udev/rules.d?) but if I comment out that rule in 99-systemd.rules, is > it sufficient to run `udevadm control --reload` to avoid being bitten by > this issue? Yes, you can comment out that rule for now in /lib/udev/rules.d/99-systemd.rules and then on next systemd update, this will be overwritten by the new rules file which will have this removed officially. And yes, udevadm control --reload should suffice. Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/2 ------------------------------------------------------------------------ On 2016-02-26T08:19:01+00:00 Peter wrote: However, I missed one point - we still need to be sure that systemd doesn't consider the device to be ready on ADD event because on ADD event, any DM device is still not ready - it needs to be loaded with teable and then resumed. So the rule should be: UBSYSTEM=="block", ACTION=="add", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0" (so it checks against 'ACTION=="add"') Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/3 ------------------------------------------------------------------------ On 2016-02-26T08:33:36+00:00 Peter wrote: *** Bug 1300453 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/4 ------------------------------------------------------------------------ On 2016-02-26T08:38:11+00:00 Peter wrote: *** Bug 1310022 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/5 ------------------------------------------------------------------------ On 2016-02-26T14:37:05+00:00 Ryan wrote: Awesome! So to summarize for anyone following this from home, until new systemd packages including this fix are shipped, you can protect yourself from this issue by tweaking that line with sed: sed -i '/DM_UDEV_DISABLE_OTHER_RULES_FLAG/s|.*|SUBSYSTEM=="block", KERNEL!="ram*", ACTION=="add", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0"|' /usr/lib/udev/rules.d/99-systemd.rules And reloading the rules: udevadm control --reload Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/6 ------------------------------------------------------------------------ On 2016-02-26T19:29:05+00:00 Matt wrote: Can you identify how far back this erroneous rule was introduced? Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/7 ------------------------------------------------------------------------ On 2016-02-29T07:39:50+00:00 Lukáš wrote: https://github.com/systemd/systemd/commit/b7cf1b68a79833411851fa547ac9b4906207c224 Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/8 ------------------------------------------------------------------------ On 2016-02-29T08:36:41+00:00 Peter wrote: The systemd rule dates back to 2011 - so very old. But this had not manifested till we added further rules for multipath where we set flags for events which are coming from multipath device reload if multipath component underneath is down or it comes up (and hence multipath device needs to be reloaded). This is kind of event for which we really don't need to trigger all the existing rules again and trigger all scanning - it's just for the multipath dm device table reload which is transparent to any layer above or any mpath device user - so that's why we added DM_UDEV_DISABLE_OTHER_RULES_FLAG for such an event - to minimize the resource usage (in this case udev rule processing). These new rules in multipath were added in RHEL7.0 then (which is also 2 years already!). This problem has not manifested yet for other dm-based devices (like LVM) because these ones don't use the DM_UDEV_DISABLE_OTHER_RULES_FLAG after the device is set up and running - these require the scans and rules to be reevaluated if there's any reload compared to the multipath device where the content of the device is not changed during reloads when one of the paths is down or up. Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/9 ------------------------------------------------------------------------ On 2016-03-01T14:50:21+00:00 Lukáš wrote: pushed to staging -> https://github.com/lnykryn/systemd-rhel/commit/d77ced281c6d1f47b5dfc3abff6817d8f5756af9 -> post Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/10 ------------------------------------------------------------------------ On 2016-04-11T09:02:29+00:00 Martin wrote: Please send such changes upstream too -- done in https://github.com/systemd/systemd/pull/3013 now. Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/14 ------------------------------------------------------------------------ On 2016-04-11T11:07:20+00:00 Lukáš wrote: Just for reference, here is the original pull request https://github.com/systemd/systemd/pull/2747 Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/16 ------------------------------------------------------------------------ On 2016-11-04T00:52:10+00:00 errata-xmlrpc wrote: Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2216.html Reply at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/comments/22 ** Changed in: systemd (Fedora) Status: Unknown => Fix Released ** Changed in: systemd (Fedora) Importance: Unknown => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1565969 Title: Udev rule causes automatic incorrect unmount of dm device Status in systemd package in Ubuntu: Fix Released Status in systemd package in Fedora: Fix Released Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' Description: Ubuntu Xenial Xerus (development b ranch) Release: 16.04 2) The version of the package you are using, via 'apt-cache policy pkgname' systemd: Installed: 229-3ubuntu1 Candidate: 229-3ubuntu1 3) What you expected to happen I am testing our E-Series Netapp storage array and the ability of the server to failover IO to the secondary path. I pull a cable and allow DM-MP to fail the path and route IO down the other path. I then replug the cable and repeat for the other path. I expect that the failover to occur and for the mount points to stay mounted through the operation. 4) What happened instead I see in the system log that during the test systemd tries to perform an unmount operation on the mountpoint of the dm-device(s) that have lost an underlying path. The unmount fails, I assume because there is active IO at the time. However it should not be attempted in the first place. I believe this is related to the bug that we discovered in RHEL and SLES that can be seen in this redhat commit: https://github.com/lnykryn/systemd- rhel/commit/d77ced281c6d1f47b5dfc3abff6817d8f5756af9 Our testing of RHEL seems to indicate that this patch resolved our problem. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: systemd 229-3ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6 Uname: Linux 4.4.0-16-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Mon Apr 4 13:56:35 2016 MachineType: Dell Inc. PowerEdge R720 ProcEnviron: TERM=xterm SHELL=/bin/bash PATH=(custom, no user) LANG=en_US ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-16-generic root=UUID=ab1330f8-0a76-4ba4-b2a2-a55f2b68b8c0 ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/systemd-timesyncd.service -> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf [EXTENDED] /lib/systemd/system/rc-local.service -> /lib/systemd/system/rc-local.service.d/debian.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/22/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.5.4 dmi.board.name: 0VWT90 dmi.board.vendor: Dell Inc. dmi.board.version: A02 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.5.4:bd01/22/2016:svnDellInc.:pnPowerEdgeR720:pvr:rvnDellInc.:rn0VWT90:rvrA02:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R720 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565969/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
