Bug 2173850
| Summary: | [DDF] add a note that performing dnf upgrade in gnome session may cause restart of the session | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Direct Docs Feedback <ddf-bot> |
| Component: | Documentation | Assignee: | Mariya Pershina <mpershin> |
| Documentation sub component: | DDF | QA Contact: | |
| Status: | CLOSED WONTFIX | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | mcatanza, otaylor, rhel-docs, rhughes, sjanderk, tpelka, tpopela |
| Version: | unspecified | Keywords: | Documentation |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-03-28 06:30:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Direct Docs Feedback
2023-02-28 06:59:10 UTC
This is very sensitive topic. It is true that executing rpm updates under Gnome is more risky, but the risk is very low. It is expected that our RPMs are solid enough to not trigger any issue. I remember a situation from Fedora where update triggered user logout and the consequence was interrupted transaction and broken system. May I ask you to provide an example when the same situation happen in RHEL? In case that there will be no known issue from RHEL I would recommend to close the issue, because strong wording related to RHEL stability could be confusing or misleading. (In reply to Jaroslav Mracek from comment #3) > This is very sensitive topic. It is true that executing rpm updates under > Gnome is more risky, but the risk is very low. It is expected that our RPMs > are solid enough to not trigger any issue. I remember a situation from > Fedora where update triggered user logout and the consequence was > interrupted transaction and broken system. May I ask you to provide an > example when the same situation happen in RHEL? In case that there will be > no known issue from RHEL I would recommend to close the issue, because > strong wording related to RHEL stability could be confusing or misleading. Unfortunately, I don't have an exact pkg or set of packages that would trigger logout, I thought it is caused by any of systemd packages but it is not. CC-ing @tpopela who mentioned that even in Fedora performing system updates from a running session is not encouraged and offline update should be the preferred option here. I don't have any examples - I will defer to Richard / Owen or Michael that might be more familiar with the history and why GNOME Software prefers the offline updates. Updating the system while it is running is just not supportable in general. All my examples of bad stuff happening are going to be from Fedora, though. Example bug report from two hours ago: bug #2180873. WebKitGTK is guaranteed to crash in exactly the same way if you update RHEL while using Evolution or yelp or whatever. I've seen many, many more but don't keep track of them all. Broken fonts after a font update, or strange bugs after an evolution-data-server update when the complaining user failed to restart the system afterward... that sort of thing. To the extent 'dnf update' while the system is running works in RHEL, that's by luck, not by design. We make no promises. And it's not fixable either; to eliminate this problem, we would need to get rid of dnf entirely and switch to rpm-ostree instead. Now, I think losing the entire desktop session is pretty unlikely, but it's certainly not impossible and a previous case of this happening in Fedora is documented here: https://lwn.net/Articles/702629/. It could happen in RHEL just the same. This article proposes a really easy workaround to avoid the most serious potential consequences: run dnf under tmux screen. That way, if the worst happens and the desktop session does crash, at least dnf itself will survive and you will not corrupt your rpmdb. Another option is to run the update from a tty rather than from a graphical terminal that's running in the desktop environment. > Now, I think losing the entire desktop session is pretty unlikely, but it's
> certainly not impossible and a previous case of this happening in Fedora is
> documented here: https://lwn.net/Articles/702629/. It could happen in RHEL
> just the same. This article proposes a really easy workaround to avoid the
> most serious potential consequences: run dnf under tmux screen.
Of course I meant: tmux or screen
Let me summarize. we know that there are reports in is in Fedora. But this is not enough - we have to know the cause. I suggest that such an issue must be handled on the level of particular component and not on distribution error. To explain that I will use an example from DNF. Removal of dependency of DNF plugin caused DNF Plugin crash with all consequences listed above. Be honest it caused more problems - broken rpm transaction => broken system. We had basically two options: 1. Document it or make a recommendation to run DNF transaction with the removal of packages without DNF plugins - in principle it is the same solution proposed in this bug report. - this solution will resolve only 90 % of the issues related to stability because it only disable one of triggers 2. Increase DNF stability to not terminate RPM transaction by plugins and prevent plugin crash - this is the more complicated solution - Personally I prefer to resolve the cause rather to recommend to not use approach that might trigger the issue The solution 1 has one consequence - prevents fixing the issue causes. I recommend to close the issue. As per the comments above, I'm closing the ticket. Thanks everyone! |