On 03/04/13 18:48, Kok, Auke-jan H wrote:
On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson <wstephen...@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@.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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
