Bug 1413284
Summary: | mcelog service is enabled after updating the package | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Kenny Tordeurs <ktordeur> |
Component: | mcelog | Assignee: | Prarit Bhargava <prarit> |
Status: | CLOSED ERRATA | QA Contact: | Andrej Manduch <amanduch> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | bhu, carsten.grohmann, cww, jcrumple, jivavra, ktordeur, mdekan, prarit |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-10 18:32:44 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: | 1420851, 1442258 |
Description
Kenny Tordeurs
2017-01-14 13:37:22 UTC
*** Bug 1413285 has been marked as a duplicate of this bug. ***
># systemctl status mcelog
>mcelog.service - Machine Check Exception Logging Daemon
> Loaded: loaded (/usr/lib/systemd/system/mcelog.service; enabled)
> Active: inactive (dead)
I don't think this means it is running, only that it has been loaded. Can you repeat your steps and also do a
ps aux | grep mce
before and after the mcelog update? If that shows /usr/sbin/mcelog running then there's definitely a problem.
P.
Hi, I've tested it and it really looks like a bug # yum install mcelog-101-3.9de4924.el7.x86_64.rpm <...> # systemctl disable mcelog Removed symlink /etc/systemd/system/multi-user.target.wants/mcelog.service. # systemctl status mcelog ● mcelog.service - Machine Check Exception Logging Daemon Loaded: loaded (/usr/lib/systemd/system/mcelog.service; disabled; vendor preset: enabled) Then I've updated and checked systemctl and it's enabled # yum status mcelog <...> # systemctl status mcelog ● mcelog.service - Machine Check Exception Logging Daemon Loaded: loaded (/usr/lib/systemd/system/mcelog.service; enabled; vendor preset: enabled) Active: inactive (dead) Checked "ps aux | grep mce" and it's not running (as stated in status) but still, it's enabled I've rebooted the machine and it's running # systemctl status mcelog ● mcelog.service - Machine Check Exception Logging Daemon Loaded: loaded (/usr/lib/systemd/system/mcelog.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-01-16 18:17:12 CET; 1h 19min left <...> (Well probably some bug with date) Just to be sure - so I've stopped and disabled the service # systemctl stop mcelog # systemctl disable mcelog Rebooted machine, and it's not running # systemctl status mcelog ● mcelog.service - Machine Check Exception Logging Daemon Loaded: loaded (/usr/lib/systemd/system/mcelog.service; disabled; vendor preset: enabled) Active: inactive (dead) I suspect this has something to do with the systemd.preset directive and that it needs to be set to disabled by default. I'll play around with the systemd files today. P. Adding a systemd.preset file will "fix" this, however, I think we have a larger issue to discuss. Since 2010, mcelog has enabled its service through %post in the rpm spec: %post systemctl enable mcelog.service &> /dev/null || systemctl daemon-reload &> /dev/null That is within the lifetime of RHEL7 and I have concerns about changing the default behaviour at this time in RHEL7. We would have to notify all customers of the change in the README and kbase articles explaining to them why the change was made, what the impact is to the end user, etc. Right now our customers are used to typing "rpm -Uvh" or "yum update" and the mcelog service is enabled. If I made this change then customers would have to additionally remember to execute "systemctl enable mcelog.service". I don't think that is the correct thing to do. I'm willing to revisit this for RHEL8, but I think we should keep the behavior of RHEL7 the same. I'm closing this as WONTFIX, for obvious reasons. I could fix it but I don't think it is the right thing to do at this stage in RHEL7. P. (In reply to Prarit Bhargava from comment #7) > Adding a systemd.preset file will "fix" this, however, I think we have a > larger issue to discuss. > > Since 2010, mcelog has enabled its service through %post in the rpm spec: > > %post > systemctl enable mcelog.service &> /dev/null || > systemctl daemon-reload &> /dev/null > > That is within the lifetime of RHEL7 and I have concerns about changing the > default behaviour at this time in RHEL7. We would have to notify all > customers of the change in the README and kbase articles explaining to them > why the change was made, what the impact is to the end user, etc. > > Right now our customers are used to typing "rpm -Uvh" or "yum update" and > the mcelog service is enabled. If I made this change then customers would > have to additionally remember to execute "systemctl enable mcelog.service". > > I don't think that is the correct thing to do. I'm willing to revisit this > for RHEL8, but I think we should keep the behavior of RHEL7 the same. > > I'm closing this as WONTFIX, for obvious reasons. I could fix it but I > don't think it is the right thing to do at this stage in RHEL7. > > P. Hello, How about this solution? It was proposed by the customer from case 01772650. It would not change the expected behaviour during the initial installation but it prevent the disabled state during a package update - that's what an admin expects! Personally I don't like such mind: Implement a workaround instead of solving the issue on the root! Suggested update for the mcelog spec file: %post case "$1" in 1) # This is an initial installation systemctl enable mcelog.service &> /dev/null || systemctl daemon-reload &> /dev/null ;; 2) # This is an upgrade - don't reactivate the service again : ;; esac This seems reasonable to me. I'll test this to make sure it works and if so I'll fix this bug. P. Hi Jiri, Because bug is in modified state, it's safe to assume it will be released with RHEL 7.5. 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:0991 |