[systemd-devel] dbus user services using the session bus

Will Stephenson wstephenson at kde.org
Wed Apr 10 07:29:34 PDT 2013


On 03/04/13 18:48, Kok, Auke-jan H wrote:
> On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson <wstephenson at kde.org> wrote:
>> I'm joining the flock of desktop people investigating using systemd to start a desktop session.  So far I've checked out user-session-units and have created some more granular unit files that will do a native systemd start rather than u-s-u's wrapper around the upstream start script.
> As Tom asked, I'm interested in these changes as well - do you have
> your code posted somewhere?

Sorry for the late response, but I wanted to get a bit further on. 
Having found a bit more time for this project I've got things working.

https://github.com/wstephenson/klyde/tree/master/startup/kde-session-units

It uses cmake to configure the service files and that uses a cmake 
module from libkde4-devel or equivalent, but if you don't want to 
install that, you can simply sed the bits between @@ in the .service.in 
files to the location of your KDE installation.

Then set systemdkde.target as default and away you go.

>
> Also, you're saying there's a "start script" somewhere, can you tell
> me what you mean by that?

http://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=21c117492268db828990ee7cc232d991ee757126&hb=a7d0ef49cb7839d42646334459f1140ed32c0a41&f=startkde.cmake

startkde sets up the basic environment for a KDE session, but the start 
of actual processes (kwin, kded, knotify, plasma, etc etc) is sequenced 
by ksmserver and started by forking off of kdeinit/klauncher.  The 
startkde script just starts kdeinit and ksmserver.

More details here:
https://github.com/wstephenson/klyde/blob/master/startup/kde-session-units/DESIGN

> I don't understand what you refer to by "wrapper", either. Technically
> user-session-units doesn't wrap anything, it just provides straight
> unit files. One of them is derivative of user at .service from systemd,
> sure.

I meant that user-session-units' kde.service runs the startkde shell 
script, which is a container for several other processes as described 
above.  For a native session I'd like to break all this out into unit files.


>> I'm stuck now, because I want to start a service with Type=dbus that puts a service on the session bus, however, I can't see a way to specify the bus in the unit file.
> you can insert variables into the user session by `systemctl --user
> set-environment DBUS_S....`. This is the only way to globally assign a
> dbus address to the session, but you'll have to do it before any
> significant service runs in the first place, which includes before
> dbus starts.

Tom was right, it Just Worked.  The problem was elsewhere; because 
kdeinit is started in a convoluted way that requires 
RemainAfterExit=true to prevent systemd killing things that should 
remain running.

The next step is to hand off as much of the complexity to systemd, 
breaking up ksmserver into individual unit files.
>> I don't want to use dbus activation here to start the service as that invokes the chicken-egg problem that the service in question (kdeinit) job is to start all the processes that will be calling it via dbus later. Long term I would like to do away with this and perform this task via systemd too, but Type=dbus on the session bus seems like a valid use case that should work.
>>
>> I see there's a way to get the dbus session bus address into systemd because of the patch to fix this in user-session-units; would the right approach be to add a BusInstance= field to service and use the provided session bus address when watching for Type=dbus services that depend on user/dbus.service?
> all of this stuff seems to work just fine with user-session-units - of
> course the login/DM integration is wholly missing right now, but could
> you start with user-session-units and make modifications to get where
> you want?

That's what I started with, thanks.  I've packaged it and its 
dependencies here: 
https://build.opensuse.org/project/show?project=home%3Awstephenson%3Aworkbench%3Asystemd

Will



More information about the systemd-devel mailing list