[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