[lfs-dev] dbus, systemd, polkit, and consolekit

Bruce Dubbs bruce.dubbs at gmail.com
Fri May 9 19:37:37 PDT 2014


I have spent the last several days trying to understand the internals of 
dbus, polkit, and consolekit in an attempt to integrate System V and 
systemd.

I have not been successful.  The linkages are not transparent at all. 
For example lxsession-logout tries to get permissions for poweroff or 
reboot in a very complex way.

It calls dbus to get permissions for systemd-logind.  While running 
System V, this fails and that is quite understandable.

It then tries consolekit.  I tried to trace it through dbus to 
console-kit-daemon and from there to polkit-1/polkitd.  I was not able 
to figure out how the decision to accept or deny a simple function like 
CanRestart is made.  The interfaces through dbus and really complex glib 
functions was beyond what I can understand without a *lot* more study. 
For example, from polkit:

g_dbus_proxy_call (authority->proxy,
     "CheckAuthorization",
     g_variant_new ("(@(sa{sv})s at a{ss}us)",
         subject_value,
         action_id,
         details_value,
         flags,
         data->cancellation_id != NULL ? data->cancellation_id : ""),
     G_DBUS_CALL_FLAGS_NONE,
     G_MAXINT, /* no timeout */
     cancellable,
     (GAsyncReadyCallback) check_authorization_cb,
     data);

I looked at the documentation and "(@(sa{sv})s at a{ss}us)" (glib) is still 
a mystery to me.  What is the proxy?  I still can't tell.

I tried to step back and see just what is all this dbus, systemd, 
polkit, and consolekit stuff all about.  My conclusion is that it is to 
manage multiple simultaneous desktops on a single system.

My question then is "In today's environment, where does all this fit 
in".  Are there many places where multiple desktop environments are 
needed on a single system?  I am certainly not aware of that.

I do have experience working on supercomputers where there are many 
users competing for run time.  The thing there is that there are no 
desktop environments.  You just ssh in and do what is needed from the 
command line.  In some cases there are web based interfaces, but 
certainly not desktops.

One advantage of systemd is to speed up the boot process by running 
multiple boot processes in parallel.  On LFS it is faster.  On my 
hardware systemd boots in 8 seconds and System V boots in 10 seconds. 
that's hardly a substantial reason for a massive complication of the 
boot process and many programs within the overall system.

I've said it before: it appears that systemd is a solution in search of 
a problem.  For 99% of users, especially LFS users, systemd provides no 
discernible benefits and a lot of problems.  You are either all in or 
not.  There does not seem to be a halfway.

Unless I get some feedback in the next couple of days with solid reasons 
that systemd, polkit, and consolekit are important, I am going to 
replace systemd with eudev in LFS and minimize recommendations for 
polkit and consolekit in BLFS.

I'm a little undecided whether dbus should remain in LFS or not.  It 
doesn't hurt much, but it also isn't much use in an non-xorg environment 
unless you are using systemd.  To use it in an xorg environment, it (at 
least dbus-launch) needs to be built after xorg-libs.

Many users come to LFS because they don't want the "bloat" of the 
commercial distros.  I am now willing to return to those roots.

Feedback is welcome.

   -- Bruce


More information about the lfs-dev mailing list