`run0` return[s/ed] "Failed to start transient service unit: Access denied"

rokejulianlockhart · December 21, 2025, 1:57pm

For P4D, as explained at:

…any invocation of run0 merely returned “Failed to start transient service unit: Access denied”. However, today, I became able to utilise it again. Does anyone have any idea what might [have] cause[d] this?

Conducted Diagnosis

I don’t believe that I’ve done as t/132430/14 explains, although I don’t understand it.
SELinux is permissive (not disabled), so bugzilla.redhat.com/show_bug.cgi?id=2421016#c3 shouldn’t affect it (and didn’t).

My Environment

This is operating as expected on:

Name        : systemd
Version     : 258.3
Release     : 2.fc43
Architecture: x86_64
Install Date: Sat 20 Dec 2025 02:10:11 GMT
Size        : 13323497
Signature   :
              RSA/SHA256, Wed 17 Dec 2025 16:06:47 GMT, Key ID 829b606631645531
Source RPM  : systemd-258.3-2.fc43.src.rpm
Build Date  : Wed 17 Dec 2025 15:47:15 GMT
Build Host  : buildvm-x86-20.rdu3.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
Bug URL     : https://bugz.fedoraproject.org/systemd

…so it was, presumably, ⪅ that.

barryascott · December 22, 2025, 9:25am

Do you have any error logs from the time that the run0 failed?

rokejulianlockhart · December 22, 2025, 10:03am

@barryascott, journalctl -b --grep='Failed to start transient service unit' returns:

-- No entries --

Any idea of where it would print logs, if it creates any?

barryascott · December 22, 2025, 11:12am

I would look at the logs around the time of the failure in the system journal.

You may not see the text you are --grep’ing for in the system journal.

rokejulianlockhart · December 22, 2025, 11:55am

@vgaetera, that’s the problem: suddenly, run0 ceased to work for a few days, then began to work again. Consequently, I want to know how to retroactively ascertain what failed, to prevent it recurring.

@barryascott, why not?! (Think it could be mangled, like strace does?)

Considering how many logs exist per boot, I don’t know where to start, without knowing what strings to search for.

Perhaps, per:

Desktop Laptop

RokeJulianLockhart@Beedell:~$ dnf5 history list --contains-pkgs=systemd
 ID Command line                                Date and time       Action(s) Altered
326 dnf upgrade -y --refresh --offline          2025-12-20 02:10:09               100
285 dnf upgrade -y --refresh --offline          2025-11-13 13:13:41                52

RokeJulianLockhart@Beedell:~$ dnf5 history list --contains-pkgs=systemd
 ID Command line                                          Date and time       Action(s) Altered
155 dnf5 upgrade -y --refresh --offline                   2025-12-21 14:53:22               360
121 dnf upgrade -y --refresh --offline                    2025-11-14 01:09:42                50

…this was remediated by:

Transaction ID : 326
Begin time     : 2025-12-20 02:10:09
Begin rpmdb    : faa5cae1fc69bd6ae6212e28d162875d0d7bb3027a8b2a732096cf8da5951ae9
End time       : 2025-12-20 02:10:27
End rpmdb      : d75e01af9f6afc407ad12fbbeffacb877df2486a10a407aa7fa38e9c3371e186
User           : 0 Super User <root>
Status         : Ok
Releasever     : 43
Description    : dnf upgrade -y --refresh --offline
Comment        : 
Packages altered:
  Action   Package                                              Reason          Repository
  Upgrade  systemd-0:258.3-2.fc43.x86_64                        Group           updates
  Upgrade  systemd-libs-0:258.3-2.fc43.x86_64                   Dependency      updates
  Upgrade  systemd-pam-0:258.3-2.fc43.x86_64                    Dependency      updates
  Upgrade  systemd-shared-0:258.3-2.fc43.x86_64                 External User   updates
  Upgrade  systemd-udev-0:258.3-2.fc43.x86_64                   Group           updates
  Upgrade  systemd-resolved-0:258.3-2.fc43.x86_64               Group           updates
  Upgrade  systemd-networkd-0:258.3-2.fc43.x86_64               Weak Dependency updates
  Upgrade  systemd-container-0:258.3-2.fc43.x86_64              Dependency      updates
  Upgrade  systemd-libs-0:258.3-2.fc43.i686                     Dependency      updates
  Upgrade  systemd-oomd-defaults-0:258.3-2.fc43.noarch          Group           updates
  Upgrade  systemd-sysusers-0:258.3-2.fc43.x86_64               External User   updates
  Upgrade  systemd-devel-0:258.3-2.fc43.x86_64                  External User   updates
  Replaced systemd-0:258.2-1.fc43.x86_64                        Group           @System
  Replaced systemd-container-0:258.2-1.fc43.x86_64              Dependency      @System
  Replaced systemd-devel-0:258.2-1.fc43.x86_64                  External User   @System
  Replaced systemd-libs-0:258.2-1.fc43.x86_64                   Dependency      @System
  Replaced systemd-libs-0:258.2-1.fc43.i686                     Dependency      @System
  Replaced systemd-networkd-0:258.2-1.fc43.x86_64               Weak Dependency @System
  Replaced systemd-oomd-defaults-0:258.2-1.fc43.noarch          Group           @System
  Replaced systemd-pam-0:258.2-1.fc43.x86_64                    Dependency      @System
  Replaced systemd-resolved-0:258.2-1.fc43.x86_64               Group           @System
  Replaced systemd-shared-0:258.2-1.fc43.x86_64                 External User   @System
  Replaced systemd-sysusers-0:258.2-1.fc43.x86_64               External User   @System
  Replaced systemd-udev-0:258.2-1.fc43.x86_64                   Group           @System

It didn’t exist for an entire month, though…

barryascott · December 22, 2025, 3:33pm

You are assume the error printed by the run0 command will match a log from systemd from another program. There is no reason it must match.

barryascott · December 22, 2025, 3:35pm

If you knew the time of the problem you can focus on logs around that time using journalctl - -since=. But if do know time it does indeed make hunting for a log harded.

glb · December 22, 2025, 4:36pm

It looks like the PAM configuration for run0 is under /usr/lib/pam.d:

$ cat /usr/lib/pam.d/systemd-run0
# SPDX-License-Identifier: LGPL-2.1-or-later
# This file is part of systemd.
#
# Used by run0 sessions

-account sufficient pam_systemd_home.so
account  required   pam_unix.so

session  required   pam_selinux.so close
session  required   pam_selinux.so open
session  required   pam_loginuid.so
session  optional   pam_keyinit.so force revoke
session  required   pam_namespace.so
-session optional   pam_systemd_home.so
session  optional   pam_umask.so silent
session  optional   pam_systemd.so
session  required   pam_unix.so

I think any line containing “required” might be able to produce that sort of access denied error message and prevent the transient service unit from starting. For example, an expired account.

rokejulianlockhart · December 22, 2025, 6:16pm

@barryascott, in retrospect, I do know, generally, that it should match the post time of the cited https://universal-blue.discourse.group/t/8214/3#xpointer(//*[@title="17 Dec 2025 16:18" and @data-time="1765988284701"]):~:text=5d, ^[1] so I can search the journal entries around that timestamp. However, journalctl --since=20251217 fails with “Failed to parse timestamp: 20251217”. What is more standard than ISO 8601? ︎

@glb, what “account” would “expire” on a local OS installation? I don’t understand.

glb · December 22, 2025, 6:22pm

You would have had to have set PASS_MAX_DAYS in /etc/login.defs for that to happen. Or run something like sudo passwd -e RokeJulianLockhart. That would be an unlikely cause. It looks like pam_unix is also required in the session stack, so, e.g., some problem writing to the system logs could have generated that error. pam_namespace is also required, so if you were doing interesting things with that configuration under /etc/security, that might cause run0 to fail. None of the possibilities seem all that likely really. I just suggested that as a place to look.

pg-tips · December 22, 2025, 6:23pm

--since=2025-12-17 works. (It looks like in ISO 8601 terms you have to use the “extended format” and not the “basic format”.)

rokejulianlockhart · December 22, 2025, 6:27pm

@pg-tips, thanks! Though, apparently, time isn’t permissible:

RokeJulianLockhart@Beedell:~$ journalctl --since=2025-12-17T16
Failed to parse timestamp: 2025-12-17T16
RokeJulianLockhart@Beedell:~$ journalctl --since=2025-12-17

That’s what I’d tried first, and why I thought it wouldn’t work. What dreadful QA. ︎

@barryascott, does anyone have any ideas of what to search for? I don’t mind just submitting a journal to a GitLab snippet, but I’d rather do the work than outsource it; that would be unfair to those already putting in time to assist.

glb · December 22, 2025, 6:32pm

According to the run0 man page, it uses polkit. Have you changed anything under /etc/polkit-1 recently? Or maybe if your polkit.service was failing that could cause it?

rokejulianlockhart · December 22, 2025, 7:50pm

@glb, no. I believe that I wanted to, but didn’t:

Is this possible to ascertain? I ask per the undermentioned:

…which hasn’t been answered.

barryascott · December 22, 2025, 7:52pm

2025-12-17 maybe?

The formats accepted are in one of the systemd man pages. Not near a Fedora system to look it up, but start with man journalctl I recall the - -since points to the right place.

glb · December 22, 2025, 7:54pm

Maybe sudo journalctl -t systemd -g failed | grep -i polkit?

grumpey · December 22, 2025, 8:06pm

you could also do:
journalctl -u polkit.service --since=2025-12-17

Edit: You could also try
journalctl --since=2025-12-17 -g '\[run0\]' -g 'user.0'

rokejulianlockhart · December 23, 2025, 6:07pm

@barryascott, indeed. @pg-tips mentioned so. Thanks, though. I am incompetent at locating anything of worth inside man pages.

@glb, on my laptop, the timestamps for the logs that are returned don’t appear to match when the error occurred:

RokeJulianLockhart@Beedell:~$ sudo journalctl -t systemd -g failed | grep -i polkit
Place your right index finger on the fingerprint reader
Nov 23 23:40:57 Beedell.RokeJulianLockhart.laptop.SKQY07 systemd[5280]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Nov 24 01:04:03 Beedell.RokeJulianLockhart.laptop.SKQY07 systemd[5280]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 22 13:49:24 Beedell.RokeJulianLockhart.laptop.SKQY07 systemd[2031]: plasma-polkit-agent.service: Failed with result 'exit-code'.

…and on my desktop, I’ve significantly too many, from too far ago:

RokeJulianLockhart@Beedell:~$ sudo journalctl -t systemd -g failed | grep -i polkit
[sudo] password for RokeJulianLockhart: 
Nov 09 01:09:49 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1657]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Nov 09 18:26:15 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1664]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Nov 19 17:53:01 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1619]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Nov 23 03:08:38 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1646]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Nov 23 20:21:07 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1487]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Nov 24 01:12:34 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1654]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Nov 27 01:15:56 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1653]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 03 15:10:45 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1575]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 07 02:00:08 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1651]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 09 14:21:42 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1494]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 09 14:25:11 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1494]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 09 18:24:26 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1494]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 10 01:16:59 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1660]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 11 18:53:00 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1670]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 11 20:22:26 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1670]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 11 20:30:53 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1670]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 12 00:40:35 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1500]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 12 23:18:19 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1497]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 13 01:33:15 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1497]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 20 02:13:14 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1656]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 20 13:28:33 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1584]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 22 00:43:01 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1495]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 22 01:21:28 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[1495]: plasma-polkit-agent.service: Failed with result 'exit-code'.
Dec 22 12:54:56 Beedell.RokeJulianLockhart.desktop.SSV2AY systemd[7070]: plasma-polkit-agent.service: Failed with result 'exit-code'.

Thanks, though.

@grumpey, that certainly returns errors, although I do not know which are relevant:

<table>
<thead>
<tr>
<th>

#### Desktop

~~~sh
#!/usr/bin/env sh
journalctl -u polkit.service --since=2025-12-17
~~~

</th>
<th>

#### Desktop

~~~sh
#!/usr/bin/env sh
journalctl --since=2025-12-17  -g '\[run0\]' -g 'user.0'
~~~

</th>
</tr>
</thead>
<tbody>
<tr>
<td>

https://gist.github.com/RokeJulianLockhart/6ad0dcb238efab04d173447c058dfc06

</td>
<td>

https://gist.github.com/RokeJulianLockhart/68b893224ad3559964408999eb2b75bc

</td>
</tr>
</tbody>
<thead>
<tr>
<th>

#### Laptop

~~~sh
#!/usr/bin/env sh
journalctl -u polkit.service --since=2025-12-17
~~~

</th>
<th>

#### Laptop

~~~sh
#!/usr/bin/env sh
journalctl --since=2025-12-17  -g '\[run0\]' -g 'user.0'
~~~

</th>
</tr>
</thead>
<tbody>
<tr>
<td>

https://gist.github.com/RokeJulianLockhart/d36924cd5e22aa6776267410db115899

</td>
<td>

https://gist.github.com/RokeJulianLockhart/68b893224ad3559964408999eb2b75bc

</td>
</tr>
</tbody>
</table>

@steppybug, not deliberately. Have you reason to believe so? (Is that code a quote?)

rokejulianlockhart · December 23, 2025, 6:52pm

Though, @steppybug, as does mere cancellation:

My brother and I have never needed to create a rule to have run0 work.

glb · December 23, 2025, 7:01pm

FWIW, it looks like there is a default rule that might return true if you are in the wheel group:

$ cat /usr/share/polkit-1/rules.d/50-default.rules 
/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */

// DO NOT EDIT THIS FILE, it will be overwritten on update
//
// Default rules for polkit
//
// See the polkit(8) man page for more information
// about configuring polkit.

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"];
});

Topic		Replies	Views
Polkit errors: not authorized Ask Fedora f37 , kde , wayland , polkit , kinoite , silverblue	15	2862	April 2, 2023
Pam_systemd(polkit-1:session) Ask Fedora	5	121	December 21, 2025
Repeated security messages from SELinux Ask Fedora kde , flatpak , selinux	29	2928	June 28, 2024
Wayland broke in Kinoite - SELinux Issue? Ask Fedora wayland , selinux , kinoite	16	1670	January 26, 2022
Login loops in Fedora 40, both xorg and wayland Ask Fedora wayland , x11 , gdm , f40	5	1200	August 27, 2025

`run0` return[s/ed] "Failed to start transient service unit: Access denied"

Conducted Diagnosis

My Environment

Related topics