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

Drew Ames jxa127 at verizon.net
Sat May 10 09:20:23 PDT 2014

On 05/09/2014 10:37 PM, Bruce Dubbs wrote:
> 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_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.
Hi Bruce,

My first response when I read what you wrote was "I do that all the 
time!" Then I thought about it more and that's not actually what I do. 
My desktop computer runs Slackware Linux and I have accounts for my 
wife, two boys, and myself. I'll often SSH into it from my laptop while 
my wife is using the desktop to run programs on the laptop (with 
x-forwarding).  So we're not really running multiple desktop 
environments at the same time.

We also often run multiple x sessions on the same computer and switch 
between them with ctrl-alt-F7 (my desktop) and ctrl-alt-F8 (my wife's). 
Both desktop environments are running and can both be active, but one is 
obviously more active than the other since we only have one keyboard and 

But we've been doing stunts like these for years (since 2006 anyway). 
Before HAL and Dbus if I remember correctly.

I guess something like the Linux Terminal Server Project, which serves 
everything -- the DE, applications, etc. to thin clients -- might be an 
application for systemd, but they've been doing their thing for a long 
time too -- without systemd.

> 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.
Agreed. A negligible boot-up time savings does not justify the change, 
in my opinion.
> 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.
To my knowledge, Slackware is still built without polkit and (maybe) 
consolekit. Not all systems need them. And (FWIW) I agree that BLFS is a 
good place for them.
> 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.
If DBUS is needed for xorg, then can it be in BLSF only?

-Drew Ames

More information about the lfs-dev mailing list