The PolicyKit program has some bugs that you may encounter.
The polkitd
program itself switches to an unprivileged user.
Then it tries to read /usr/local/share/polkit-1/rules.d/
, /usr/local/etc/polkit-1/rules.d/
, and /var/run/ConsoleKit/
.
Sometimes /usr/local/share/polkit-1/rules.d/
is installed owned by the superuser with rwx------
permissions, and so not accessible to the unprivileged user.
Sometimes /usr/local/etc/polkit-1/rules.d/
is installed owned by the superuser with rwx------
permissions, and so not accessible to the unprivileged user.
Sometimes /usr/local/etc/polkit-1/
is installed owned by the superuser with rwxr-x---
permissions, and so not accessible to the unprivileged user.
Sometimes the ConsoleKit service is simply not running.
The polkitd
program's failure mode in such scenarios is to keep trying, incessantly, to access these, every few seconds.
This is visible as the dæmon constantly consuming (some) CPU time and continually appearing in the listings of top -I
and suchlike.
The fix for the cases of /usr/local/share/polkit-1/rules.d/
, /usr/local/etc/polkit-1/rules.d/
, and /usr/local/etc/polkit-1/
is to grant the unprivileged user read and execute access to them.
The fix for the case of /var/run/ConsoleKit/
is either to create it by hand or to run the ConsoleKit service (whose service bundle creates it as a "runtime directory" for the service, removing it when the service is shut down).