Bug 2055117
| Summary: | After an IPU, sar logs are not updated anymore | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Christophe Besson <cbesson> |
| Component: | leapp-repository | Assignee: | Petr Stodulka <pstodulk> |
| Status: | CLOSED ERRATA | QA Contact: | Upgrades and Supportability <upgrades-and-supportability> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.9 | CC: | alakatos, bwelterl, ggrimaux, mmacura, pstodulk, rmetrich |
| Target Milestone: | rc | Keywords: | Reproducer, WorkAround |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | leapp-repository-0.17.0-3.el7_9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-05-17 15:00:24 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: | |||
|
Description
Christophe Besson
2022-02-16 10:27:44 UTC
Hello dev, This is a global issue here, which has similar root cause than BZ #2032953. In a nutshell, upon upgrading, leapp needs to execute "systemctl preset-all" then restore customizations made by the user (if the user disabled a service which was enabled in preset, then the service needs to be disabled in final state). Probably some algo like the one below can be implemented: At leapp pre-upgrade time 1. For each service, detect if its vendor state has been altered e.g. systemctl status rsyslog [...] Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; disabled; vendor preset: enabled) [...] At leapp post-upgrade time 2. Execute preset-all 3. Disable/Enable customized services to match previous state Hi Renaud. The generic solution around services is on our board, however not sure when we will be able to work on that - definitely it's not going to be part of the upcoming release - but there is high chance it will be part of the additional one. Our current plan is similar to what you described, with some other stuff around. For this particular problem, I am adding now @alakatos as he is maintainer of rsyslog package. Aah. Sorry for confusions. Somewhere between hell and eden I've started to thing this BZ is about rsyslog. @alakatos: Sorry for the noise. (In reply to Petr Stodulka from comment #5) > Aah. Sorry for confusions. Somewhere between hell and eden I've started to > thing this BZ is about rsyslog. > > @alakatos: Sorry for the noise. It's okay. If you think that the root cause might be coming from rsyslog, feel free to mention me/add me to the CC list. Hello,
The issue is that post install script are not executed (expected for a normal upgrade):
----
if [ $1 -eq 1 ] ; then
# Initial installation
systemctl --no-reload preset sysstat.service sysstat-collect.timer sysstat-summary.timer &>/dev/null || :
fi
----
But it is expected that this has been executed one time, from a previous rpm install. But the previous rpm was a RHEL7 one, with this:
---
if [ $1 -eq 1 ] ; then
# Initial installation
systemctl preset sysstat.service >/dev/null 2>&1 || :
fi
---
=> thus only sysstat service was managed in RHEL7 (of course, no timer, because based on crond).
Then we have only sysstat enabled, without required timer services to collect data...
Don't really know if this should be fixed in sysstat rpm (check that all service + timer are enabled) or should be checked by leapp.
Thank you !
Hi Welterlen. It can be fixed wherever maintainers prefer. It's up to them whether they prefer to fix it inside leapp-repository or their rpms. Should be fixed by the upstream PR: - https://github.com/oamg/leapp-repository/pull/972 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 (leapp and leapp-repository bug fix and enhancement update), 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-2023:3187 *** Bug 2054766 has been marked as a duplicate of this bug. *** |