Bug 2150212
| Summary: | Many "Failed to start Application launched by gnome-session-binary" errors after fresh install RHEL 9 ISO on UEFI boot | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | VIRENDRASINGH RAJPUT <vrajput> |
| Component: | gnome-desktop3 | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.1 | CC: | dtardon, hpa, jadahl, litian, mcatanza, rstrode, sbarcomb, tpopela, xuli, xxiong, yacao, yuxisun |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-04-17 14:42:15 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
VIRENDRASINGH RAJPUT
2022-12-02 05:46:07 UTC
(In reply to VIRENDRASINGH RAJPUT from comment #0) > Jul 15 13:42:03 192-168-112-197 systemd[3544]: app-gnome-user\x2ddirs\x2dupdate\x2dgtk-4070.scope: Couldn't move process 4070 to requested cgroup '/user.slice/user-0.slice/user/app.slice/app-gnome-user\x2ddirs\x2dupdate\x2dgtk-4070.scope': > No such process > Jul 15 13:42:03 192-168-112-197 systemd[3544]: app-gnome-user\x2ddirs\x2dupdate\x2dgtk-4070.scope: Failed to add PIDs to scope's control group: No such process > Jul 15 13:42:03 192-168-112-197 systemd[3544]: app-gnome-user\x2ddirs\x2dupdate\x2dgtk-4070.scope: Failed with result 'resources'. This has been reported as https://gitlab.gnome.org/GNOME/gnome-desktop/-/issues/160. Moving to gnome-desktop and adding also the uresourced maintainer (the issue should probably be moved to her). I think this is a gnome-desktop bug, not a uresourced bug, although it is certainly related to uresourced. I posted some suggestions to resolve it in the upstream issue. dtardon do you know off hand if there's a way to make systemd mum for this type of situation? (In reply to Ray Strode [halfline] from comment #3) > dtardon do you know off hand if there's a way to make systemd mum for this > type of situation? The only way I can think of is to set LogLevelMax= for the scope, as that is applied also for log messages about the unit in recent versions of systemd. The problem is that at least one of the messages is a warning, which means you'd have to set LogLevelMax=error to get rid of them. I'm pretty sure that's not desirable. > > Jul 15 13:42:03 192-168-112-197 systemd[3544]: app-gnome-user\x2ddirs\x2dupdate\x2dgtk-4070.scope: Couldn't move process 4070 to requested cgroup '/user.slice/user-0.slice/user/app.slice/app-gnome-user\x2ddirs\x2dupdate\x2dgtk-4070.scope': > No such process We've seen this before (bug 2009307), but it appeared to be a rare issue, so nobody has really looked into it. I suggest opening an upstream issue, though. It will likely get more traction there. The warnings are benign. As I understand it, gnome-session sometimes uses systemd to start services, and sometimes launches session services itself. In the case that it's launching a service itself, it still wants to integrate with systemd as much as possible, so systemd knows about the service and can provide resource management for it. It does this integration work, by asking systemd to create "transient" service associated with the already running pid. The problem is that not all services started by gnome-session at start up last very long. Some services are one-off things that start and stop very quickly. gnome-session will still try to integrate those services with systemd and systemd will report an error to the log because they'll already be finished before it can do the integration work. Systemd has no good way to turn off the error reporting in this benign case without turning off error reporting for more serious cases. One way that was proposed upstream to fix this, is to make gnome-session freeze the started process with a SIGSTOP signal until systemd is finished setting up the transient service. That would avoid the error message, but suspending active processes while they're running in an uncontrolled fashion has the potential to cause problems, but it might work okay in practice. three other potential ideas: 1. Add some mechanism to systemd to make it quiet if the pid doesn't exist. StartTransientUnit already has a array of string-value pairs. We could add a new one to mute it for this particular failure case 2. We could create the transient unit at fork time instead of exec time, and defer the exec until it finishes 3. We could create the transient unit for services that are still running ~10 seconds after they're started (or something). This would avoid the any one shot services from getting integrated into systemd But the messages are benign, and I'm not sure there's a big value from doing any of these types of changes. devnak unless we get business justification from customer or partner. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |