My first guess is "none of the above" but rather the client program (run0 in this case) that has sent off the method_call and was waiting for reply.
Polkit prompting is invisible to the client – even if the actual prompter has been spawned directly by run0 as a child process, run0 doesn't control it directly. Instead systemd receives the initial method_call and "in background" sends off another call to polkitd, which then either approves/rejects directly or triggers an interactive auth prompt. During the prompt, run0 just sits there waiting for the "StartUnit" call to do something. It *could* also potentially be systemd timing out waiting for a response from polkitd – I'm pretty sure it's not going to be polkitd timing out waiting for a response from the agent/prompter – but run0/systemd-run is generally the first place I'd check based on how the error message looks. I think programs that make calls potentially triggering interactive polkit auth generally have *much* longer timeouts than a minute. Not sure if infinite, but e.g. polkit's own `pkexec` seems to be happy to wait until my screensaver kicks in. On Tue, Aug 18, 2026, 19:29 Steven Mulvay <[email protected]> wrote: > Hi All, > > When I'm trying to authenticate for a systemd-related function (run0 > for example) and it times-out while waiting for the password, is it > likely to be: systemd timing out, dbus timing out, or polkit timing > out? Note that when it times out, I get the following error: > > Failed to start transient service unit: Method call timed out > > The reason I want to know which component is timing out, is because > I'd like to extend the timeout to at least 60 seconds if possible. I > am a very slow typist due to a physical disability. > > Many thanks, > Steven_M >
