Description of problem: uresourced constantly crash at the beginning of the session since I migrated to fedora 36 Version-Release number of selected component: uresourced-0.5.1-1.fc36 Additional info: reporter: libreport-2.17.1 backtrace_rating: 4 cmdline: /usr/libexec/uresourced --user crash_function: r_app_monitor_start executable: /usr/libexec/uresourced journald_cursor: s=eecd6e36a30748ed91cd82f662a13784;i=60722;b=a5b66863d3ef4e7a9c3904a0c71d673a;m=a9f958e;t=5da8302346b87;x=4426a082428930ef kernel: 5.17.0-0.rc7.116.fc36.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1866660 [details] File: backtrace
Created attachment 1866661 [details] File: cgroup
Created attachment 1866662 [details] File: core_backtrace
Created attachment 1866663 [details] File: cpuinfo
Created attachment 1866664 [details] File: dso_list
Created attachment 1866665 [details] File: environ
Created attachment 1866666 [details] File: limits
Created attachment 1866667 [details] File: maps
Created attachment 1866668 [details] File: mountinfo
Created attachment 1866669 [details] File: open_fds
Created attachment 1866670 [details] File: proc_pid_status
Created attachment 1866671 [details] File: var_log_messages
still get this error each time I login
Funny, I am curious, what kind of session are you logging in to? I suppose, the explanation is that you don't yet have app.slice at the time of uresourced starting up. There are two simple ways of fixing that.
Hi Benjamin, I'm using a standard Fedora 36 with GNOME installed, the only special thing is I've update this workstation along the year from Fedora 20 (not sure) every 6 months. Best.
FEDORA-2022-33dcbfb7c3 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-33dcbfb7c3
FEDORA-2022-33dcbfb7c3 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-33dcbfb7c3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-33dcbfb7c3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hi, I also have this problem of uresourced crashing when starting my Gnome session under Fedora 36, but the problem persists after installing the update above. The problem reporting tool points me to this report here: https://retrace.fedoraproject.org/faf/reports/364212/ Let me know if you need more information or if I should open a new issue with the problem.
I was convinced the update would fix this ... https://retrace.fedoraproject.org/faf/reports/364212/ The report is not very useful unfortunately (it seems to be missing the relevant stack frame). Could you either try to fetch the full backtrace or just check `journalctl --user -u uresourced.service` for the assertion you are running into?
Created attachment 1872123 [details] Core and backtrace of the persisting issue
Just uploaded the core file and backtrace. Hope it helps. 🤞
Also the journalctl output looks like this: Apr 13 08:51:25 localhost.localdomain systemd[3081]: Starting uresourced.service - User resource assignment daemon... Apr 13 08:51:25 localhost.localdomain uresourced[3211]: Failed inotify_add_watch for app.slice directory. Apr 13 08:51:25 localhost.localdomain systemd-coredump[3218]: Process 3211 (uresourced) of user 1000 dumped core. Module linux-vdso.so.1 with build-id 44055b880e9c5f40b88e7e8f2daad800142cc4ae Module libgpg-error.so.0 with build-id a53c231739d55cc39b97e28c36cd8b3e58a8f8f8 Metadata for module libgpg-error.so.0 owned by FDO found: { "type" : "rpm", "name" : "libgpg-error", "version" : "1.45-1.fc36", "architecture" : "x86_64", "osCpe" : "cpe:/o:fedoraproject:fedora:36" } Module libpcre2-8.so.0 with build-id 2827cb8b86a0a697fa6e6646690d1b01de9b6fba Metadata for module libpcre2-8.so.0 owned by FDO found: { "type" : "rpm", "name" : "pcre2", "version" : "10.39-1.fc36.1", "architecture" : "x86_64", "osCpe" : "cpe:/o:fedoraproject:fedora:36" } Module libblkid.so.1 with build-id 9e58123c73f92b29e14b080448cade11b65edde2 Metadata for module libblkid.so.1 owned by FDO found: { "type" : "rpm", "name" : "util-linux", "version" : "2.38-0.2.fc36", "architecture" : "x86_64", "osCpe" : "cpe:/o:fedoraproject:fedora:36" } Module ld-linux-x86-64.so.2 with build-id 997994d4535f8c791738540c3e6ee8e46a752603 Module libgcrypt.so.20 with build-id ff03e5dff0c164925ad3b8ad1c3143a8eb8b1f9c Stack trace of thread 3211: #0 0x00007faa76959897 g_log_structured_array (libglib-2.0.so.0 + 0x59897) #1 0x00007faa76959b62 g_log_default_handler (libglib-2.0.so.0 + 0x59b62) #2 0x00007faa76959dc2 g_logv (libglib-2.0.so.0 + 0x59dc2) #3 0x00007faa7695a073 g_log (libglib-2.0.so.0 + 0x5a073) #4 0x0000556732bde6cc main (uresourced + 0x66cc) #5 0x00007faa76316590 __libc_start_call_main (libc.so.6 + 0x2d590) #6 0x00007faa76316649 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2d649) #7 0x0000556732bdec75 _start (uresourced + 0x6c75) Stack trace of thread 3215: #0 0x00007faa763f2e8f __poll (libc.so.6 + 0x109e8f) #1 0x00007faa769aa0dd g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xaa0dd) #2 0x00007faa769528e0 g_main_context_iteration (libglib-2.0.so.0 + 0x528e0) #3 0x00007faa76952931 glib_worker_main (libglib-2.0.so.0 + 0x52931) #4 0x00007faa7697f172 g_thread_proxy (libglib-2.0.so.0 + 0x7f172) #5 0x00007faa7637a017 start_thread (libc.so.6 + 0x91017) #6 0x00007faa763ff6d0 __clone3 (libc.so.6 + 0x1166d0) ELF object binary architecture: AMD x86-64 Apr 13 08:51:25 localhost.localdomain systemd[3081]: uresourced.service: Main process exited, code=dumped, status=5/TRAP Apr 13 08:51:25 localhost.localdomain systemd[3081]: uresourced.service: Failed with result 'core-dump'. Apr 13 08:51:25 localhost.localdomain systemd[3081]: Failed to start uresourced.service - User resource assignment daemon.
Yikes. So the Requires=app.slice was not enough, apparently we also need an After=app.slice. I thought Requires= would imply After= in this case. My bad really.
I was not able to reproduce the issue locally. If you can reliably reproduce it, can you try to adding `After=app.slice` to /usr/lib/systemd/user/uresourced.service and verify that this fixes the issue? If not, no worries. I can just push out the fix, and we'll see in the crash reports whether it is disappearing.
I edited the unit file as requested and then rebooted just in case, but it doesn't seem to fix the issue for me. Apparently I get the same crash. Unit file ------------------ $ cat /usr/lib/systemd/user/uresourced.service [Unit] Description=User resource assignment daemon Requires=app.slice After=app.slice Before=graphical-session.target PartOf=graphical-session.target [Service] # This daemon needs to be in the root slice so that the system daemon can # detect it easily by checking whether the cgroup path exists. Slice=-.slice Type=notify ExecStart=/usr/libexec/uresourced --user TimeoutStopSec=5s ProtectSystem=strict RestrictAddressFamilies=AF_UNIX -------------------
Created attachment 1872297 [details] Log and core after modifying the service file
FEDORA-2022-33dcbfb7c3 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2085091 has been marked as a duplicate of this bug. ***
*** Bug 2087192 has been marked as a duplicate of this bug. ***
*** Bug 2087998 has been marked as a duplicate of this bug. ***
*** Bug 2090107 has been marked as a duplicate of this bug. ***
*** Bug 2090406 has been marked as a duplicate of this bug. ***
This bug was closed with the update that modified the unit file, if I recall correctly, but it doesn't seem to be fixed. It still happens from time to time on my system and bugs keep to be marked as duplicates of this one.
*** Bug 2091444 has been marked as a duplicate of this bug. ***
*** Bug 2091685 has been marked as a duplicate of this bug. ***
*** Bug 2093813 has been marked as a duplicate of this bug. ***
Hi guys, this bug is happening on my machine every day multiple times. Sometimes I'm only logged out, sometimes the machine restarts. This sucks a lot as it happens randomly and all unsaved data is everytime lost... Any progress or workarounds?
*** Bug 2095984 has been marked as a duplicate of this bug. ***
*** Bug 2096092 has been marked as a duplicate of this bug. ***
I've been seeing instability in both gnome-shell/wayland & kde/plasma desktops for a while; today they both started crashing though. It looks as though the bug may need reopening as recent changes may have reawakened it?
*** Bug 2096165 has been marked as a duplicate of this bug. ***
*** Bug 2096349 has been marked as a duplicate of this bug. ***
No, it was never properly fixed, reopening (fix is already incoming). A Requires= dependency is not sufficient. We also need to add an After= ordering rule to guarantee the cgroup directory exists. That said, uresourced crashing like this should not have any further side effects. Everything should just continue to work fine.
FEDORA-2022-921d59d9f6 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-921d59d9f6
FEDORA-2022-921d59d9f6 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-921d59d9f6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-921d59d9f6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The update doesn't seem to have fixed the SIGTRAP error; Looking at https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS it seems some of the sysfs endpoints must now be obsolete? for instance `/sys/fs/cgroup/user.slice/memory.low` could potentially now be in `/sys/fs/cgroup/memory/user.slice/memory.*` though there is no obvious equivalent of `memory.low` among the alternatives As for the desktop instability, I can't specifically say it's the 'fault' of `uresourced`; the symptoms are quite graphics/memory-connected though; possibly a secondary consequence of `uresourced` not running?
I found what it is for me, is that uresourced is not handling cgroup v1 gracefully; I found systemd.unified_cgroup_hierarchy=0 in my cmdline that may be docker's fault.
Ugh, I think docker might not be able to handle cgroup v2 properly? tbh. I think that is a separate bug. I am happz to add `ConditionControlGroupController=v2` to the .service files to disable uresourced if cgroup v1 is used. Do you mind quickly opening a new issue for that? While the it is the same assertions, I do believe there are two separate issues here.
I've unmarked https://bugzilla.redhat.com/show_bug.cgi?id=2096349 as duplicate, hope that's the right way :-)
Dont know if it is important or not. I had the problem with uresourced when cgroups v1 was enabled in the kernel. I changed from cgroups v1 to v2 and now every thing is working ( Fedora 36 ). Also docker is running correctly.
FEDORA-2022-921d59d9f6 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
The problem still exists. I run on the new version for three days now and from a subjective point of view the problem has become less now only once a day before it was sometimes 5x a day.
I don't think it can be this particular bug (this bug should only happen at login time). Unless you are on cgroupv1, in which case this MR would not have helped at all. It can be that you are hitting some other issue (like the issue processing pipewire events). Please provide more information about the issue you are having so that we can track it down. `coredumpctl` should be able to provide a backtrace.
(In reply to Mark from comment #47) > I found what it is for me, is that uresourced is not handling cgroup v1 > gracefully; I found systemd.unified_cgroup_hierarchy=0 in my cmdline that > may be docker's fault. Oh, thank you! I had installed Docker in the past and also had that option added to the kernel's command line (I had completely forgotten about it). I no longer use Docker, so I've removed the option and haven't had a uresourced crash on session start since then.
*** Bug 2105206 has been marked as a duplicate of this bug. ***
*** Bug 2111838 has been marked as a duplicate of this bug. ***
*** Bug 2112404 has been marked as a duplicate of this bug. ***
*** Bug 2115470 has been marked as a duplicate of this bug. ***
*** Bug 2121467 has been marked as a duplicate of this bug. ***
*** Bug 2126579 has been marked as a duplicate of this bug. ***
*** Bug 2126798 has been marked as a duplicate of this bug. ***
*** Bug 2130103 has been marked as a duplicate of this bug. ***
*** Bug 2133527 has been marked as a duplicate of this bug. ***
*** Bug 2135423 has been marked as a duplicate of this bug. ***
*** Bug 2152337 has been marked as a duplicate of this bug. ***
*** Bug 2158530 has been marked as a duplicate of this bug. ***
*** Bug 2159202 has been marked as a duplicate of this bug. ***
*** Bug 2160063 has been marked as a duplicate of this bug. ***