remote login via ssh stalls for about 30sec. This seems to happen when polkitd could not be started by systemd. I'm not sure about the circumstances: sometimes after a reboot polkitd is startable, sometimes it is not. My system: Linux 4.1.13-1-ARCH polkit 0.113-4 libsystemd 227-1 I've modified also the polkit.service file and removed the no-debug-flag, but don't see any error messages except the Timeout-meesage: Nov 22 11:45:40 mars polkitd[7474]: Successfully changed to user polkitd Nov 22 11:45:40 mars polkitd[7474]: Started polkitd version 0.113 Nov 22 11:45:40 mars polkitd[7474]: 11:45:40.342: Loading rules from directory /etc/polkit-1/rules.d Nov 22 11:45:40 mars polkitd[7474]: 11:45:40.343: Loading rules from directory /usr/share/polkit-1/rules.d Nov 22 11:45:40 mars dbus[214]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Nov 22 11:45:40 mars polkitd[7474]: 11:45:40.368: Finished loading, compiling and executing 2 rules Nov 22 11:45:40 mars polkitd[7474]: Entering main event loop Nov 22 11:45:40 mars polkitd[7474]: Connected to the system bus Nov 22 11:45:40 mars polkitd[7474]: 11:45:40.426: Acquired the name org.freedesktop.PolicyKit1 on the system bus Nov 22 11:45:40 mars polkitd[7474]: 11:45:40.543: Registered Authentication Agent for unix-process:7467:4291719 (system bus name :1.40 [/usr/bin/pkttyagent --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8) Nov 22 11:47:10 mars systemd[1]: polkit.service: Start operation timed out. Terminating. Nov 22 11:47:10 mars systemd[1]: polkit.service: Unit entered failed state. Nov 22 11:47:10 mars systemd[1]: polkit.service: Failed with result 'timeout'.
Thanks for your report. (In reply to hp4everything from comment #0) > Nov 22 11:45:40 mars polkitd[7474]: 11:45:40.426: Acquired the name > org.freedesktop.PolicyKit1 on the system bus This is pretty much the end of polkit initialization… > Nov 22 11:45:40 mars polkitd[7474]: 11:45:40.543: Registered Authentication > Agent for unix-process:7467:4291719 (system bus name :1.40 … and this shows that polkitd is already in its main loop, processing requests. So this suggests that something might be wrong with systemd detecting that the service initialization has completed, or perhaps with the unit configuration, at least as a first place to rook.
Thanks for your answer, but what should I do next as a normal user? Looking in Google shows that this problem occurs sporadically already since many versions of systemd or polkitd, but I was not able to find anyone who has found an explanation. The problem seems to disappear or reappear after system boot in an unforeseeable manner. Who is responsible for the final communication for informing systemd of reaching the polkitd's main loop? At least running polkit in debug mode doesn't show a hint that a message was sent to systemd? Or did I miss any log-files? Is it possible to trace the messages exchanged between polkitd and systemd? Should the bug report be rerouted to systemd and can you do this?
AFAICS there is no explicit polkit code indicating finished startup to systemd; systemd should take care of it all due to > Type=dbus > BusName=org.freedesktop.PolicyKit1 So, obviously, there are also no other logs about the nonexistent communication. The > Acquired the name org.freedesktop.PolicyKit1 on the system bus log entry indicates the event systemd is supposedly waiting on. Yes, following up on the systemd bug tracker might be useful. They are hosting it at https://github.com/systemd/systemd/issues , so I’m afraid I can’t directly reassign; please file a new issue there (feel free to link back here).
thanks for the help btw : who kills polkitd? Why are there no log entries about the process end? At least after systemd's report of the timeout no polkitd-process can be found in the process table! Is the running polkitd killed by systemd? Or does polkitd itself decide to shutdown without any hint in the system logs?
If polkitd terminates voluntarily, it writes > Shutting down in the same way it writes > Entering main event loop Of course it is possible to terminate it (e.g. with SIGKILL) in such a way that it has no opportunity to write anything anywhere. Given the “Terminating” log from systemd that is just what might be happening but that would be a systemd question.
Thanks. I've opened a new bug report for systemd https://github.com/systemd/systemd/issues/2019
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.