Bug 1312011
| Summary: | Fix rule setting SYSTEMD_READY=0 for DM devices (like multipath) which may cause improper automatic unmounts | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Peter Rajnoha <prajnoha> | |
| Component: | systemd | Assignee: | systemd-maint | |
| Status: | CLOSED ERRATA | QA Contact: | Branislav Blaškovič <bblaskov> | |
| Severity: | high | Docs Contact: | ||
| Priority: | urgent | |||
| Version: | 7.3 | CC: | bblaskov, fkrska, matt.schulte, mpitt, ng-hsg-engcustomer-iop-bz, qguo, rsawhill, Ryan.Rodine, systemd-maint-list, yhuang | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | systemd-219-20.el7 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1314693 (view as bug list) | Environment: | ||
| Last Closed: | 2016-11-04 00:52:10 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1269644, 1310022, 1314693 | |||
(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? (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. 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"')
*** Bug 1300453 has been marked as a duplicate of this bug. *** *** Bug 1310022 has been marked as a duplicate of this bug. *** 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
Can you identify how far back this erroneous rule was introduced? 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. pushed to staging -> https://github.com/lnykryn/systemd-rhel/commit/d77ced281c6d1f47b5dfc3abff6817d8f5756af9 -> post Please send such changes upstream too -- done in https://github.com/systemd/systemd/pull/3013 now. Just for reference, here is the original pull request https://github.com/systemd/systemd/pull/2747 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 |
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).