Bug 1525981
| Summary: | systemd failing to start sbd doesn't prevent pacemaker-start | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Klaus Wenninger <kwenning> | |
| Component: | sbd | Assignee: | Klaus Wenninger <kwenning> | |
| Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> | |
| Severity: | high | Docs Contact: | Steven J. Levine <slevine> | |
| Priority: | high | |||
| Version: | 7.5 | CC: | aherr, cfeist, cluster-maint, kgaillot, kwenning, mlisik, slevine | |
| Target Milestone: | rc | |||
| Target Release: | 7.5 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | sbd-1.3.1-7.el7 | Doc Type: | Bug Fix | |
| Doc Text: |
Pacemaker no longer starts up when "sbd" is enabled but not started successfully by "systemd"
Previously, if "sbd" did not start properly, "systemd" would still start Pacemaker. This would lead to "sbd" poison pill triggered reboots not being performed without this being detected by "fence_sbd" and, in the case of quorum-based watchdog fencing, the nodes losing quorum would not self-fence either. With this fix, if "sbd" does not come up properly Pacemaker is not started. This should prevent all sources of data curruption due to "sbd" not coming up.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1593254 (view as bug list) | Environment: | ||
| Last Closed: | 2018-04-10 16:55:50 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: | 1593254, 1693266 | |||
|
Description
Klaus Wenninger
2017-12-14 14:21:35 UTC
Even simpler fix: sbd.service: ... [Install] ... RequiredBy=pacemaker.service (In reply to Klaus Wenninger from comment #2) > Even simpler fix: > > sbd.service: > ... > [Install] > ... > RequiredBy=pacemaker.service Sounds good :) However the target idea is interesting on its own ... perhaps a 'cluster-layer.target' that includes any components below pacemaker in the cluster stack. That might simplify supporting multiple cluster-layer implementations again in the future. True - we should think the target-idea over. But for now I would suggest to go with the solution suggested in https://github.com/ClusterLabs/sbd/pull/39 as it solves the issue with a change in just a single package. A solution touching multiple packages would as well introduce strict version dependencies to work properly. With https://github.com/ClusterLabs/sbd/pull/42 such a conditional reenabling would be added. I was kind of surprised that this isn't being taken care of somehow automatically or that systemd-rpm-scriptlet-macros under /lib/rpm/macros.d/macros.systemd wouldn't at least provide a macro for that purpose. (In reply to Klaus Wenninger from comment #10) See a controversal discussion on the pull-request. Personally I'm not so convinced that an automatized reenable is that good an idea. Actually the missing update of the dependency-links is a general issue. I don't even think there is a need to document it - maybe in a release note that states the bug fixes. Actually the man-page of systemctl is quite explicit on that topic already: reenable NAME... Reenable one or more unit files, as specified on the command line. This is a combination of disable and enable and is useful to reset the symlinks a unit is enabled with to the defaults configured in the "[Install]" section of the unit file. Steven: Yes, changed a lot but I guess it still says what I meant. But it leaves the impression that sbd is always needed by pacemaker. Guess if we alter the first sentence a little bit that should clarify the issue. 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://access.redhat.com/errata/RHBA-2018:0924 |