Fedora Account System
Red Hat Associate
Red Hat Customer
Version-Release number of selected component: systemd-256.11-1.fc41 Additional info: reporter: libreport-2.17.15 type: CCpp reason: systemd-logind killed by SIGABRT journald_cursor: s=cdc53c26a65e4c9a85ad690e0c709ee4;i=d9574;b=c054be4733044b458db5e3546e4acb9a;m=4419bb239;t=62f431563f857;x=10da6c1d25efc79a executable: /usr/lib/systemd/systemd-logind cmdline: /usr/lib/systemd/systemd-logind cgroup: 0::/system.slice/systemd-logind.service rootdir: / uid: 0 kernel: 6.13.4-200.fc41.x86_64 package: systemd-256.11-1.fc41 runlevel: N 5 backtrace_rating: 4 crash_function: async_polkit_read_reply Truncated backtrace: Thread no. 1 (14 frames) #5 async_polkit_read_reply at ../src/shared/bus-polkit.c:269 #6 async_polkit_process_reply at ../src/shared/bus-polkit.c:337 #7 async_polkit_callback at ../src/shared/bus-polkit.c:391 #8 process_reply at ../src/libsystemd/sd-bus/sd-bus.c:2838 #9 process_message at ../src/libsystemd/sd-bus/sd-bus.c:3019 #10 process_running at ../src/libsystemd/sd-bus/sd-bus.c:3081 #11 bus_process_internal at ../src/libsystemd/sd-bus/sd-bus.c:3309 #12 sd_bus_process at ../src/libsystemd/sd-bus/sd-bus.c:3336 #13 io_callback at ../src/libsystemd/sd-bus/sd-bus.c:3678 #14 source_dispatch at ../src/libsystemd/sd-event/sd-event.c:4223 #15 sd_event_dispatch at ../src/libsystemd/sd-event/sd-event.c:4844 #16 sd_event_run at ../src/libsystemd/sd-event/sd-event.c:4905 #17 manager_run at ../src/login/logind.c:1217 #18 run at ../src/login/logind.c:1265 Potential duplicate: bug 2249090
Created attachment 2078717 [details] File: proc_pid_status
Created attachment 2078718 [details] File: maps
Created attachment 2078719 [details] File: limits
Created attachment 2078720 [details] File: environ
Created attachment 2078721 [details] File: open_fds
Created attachment 2078722 [details] File: mountinfo
Created attachment 2078723 [details] File: os_info
Created attachment 2078724 [details] File: cpuinfo
Created attachment 2078725 [details] File: core_backtrace
Created attachment 2078726 [details] File: dso_list
Created attachment 2078727 [details] File: var_log_messages
Created attachment 2078728 [details] File: backtrace
I can think of only one way this could happen: a D-Bus message handler had asked to authorize for an action, which was denied, but the function continued nevertheless and asked to authorize another action. Unfortunately, as the polkit auth. is asynchronous, it's not possible to see where the request comes from. If at least there were a coredump here, I could examine the AsyncPolkitQuery object to see which action caused this... Do you remember--or guess--the command that triggered this?
A random thought: as processing of PolicyKit checks for a method is currently expected to be cancelled on a first failure, maybe this check should be done already in bus_verify_polkit_async_full(), either as an assert or an early return. It doesn't make sense to send another request to polkit if we've been denied once already.
> Do you remember--or guess--the command that triggered this? Cannot exactly remember. Could be that this crash happened while I was browsing with google-chrome or just launched signal-desktop (open-suse version, repo: network_im_signal). Just wondering could this happen if I denied a command line process elevation request? For example, if I apply a 'dnf install ...' command. It pops up for entering password but I cancel the prompt for entering password / reject elevation request?
(In reply to Atiq from comment #15) > Just wondering could this happen if I denied a command line process > elevation request? Yes, that's exactly the case. > For example, if I apply a 'dnf install ...' command. It > pops up for entering password but I cancel the prompt for entering password > / reject elevation request? Not dnf, though. It would have to be a systemd tool, like systemctl, loginctl, journalctl, etc. Anyway, https://github.com/systemd/systemd/pull/36661 has been merged upstream, which should prevent this situation happening in the future. That means that the exact cause is more of a case of general interest. I'm closing the bug now, as it's (almost) a single occurrence (we had another one like it a couple of months ago, but that's all), hence it doesn't seem worth the effort to backport the upstream change.