musings on session service mgmt
After investigating (please read the full report including links to
I realized what an incredibly poor state session service management is
in and what kind of hoops upstream authors jump through because neither
X11, nor xdg or GNOME has provided them with useful infrastructure. It
looks like KDE has _some_ kind of infrastructure for this.
There are basically two problems that we've been ignoring and hacking
around for as long as I've used Linux on the desktop
1. There is no good way of starting session services that needs to
export environment variables. While one may rightfully argue this is
utter crack in most cases, things like seahorse-agent demonstrates
that this is sometimes needed. Also, you surely need to do this for
the session message bus.
2. I think we've all experienced this one or more times; you log out
of your session and log back in. Wow, now things are weird or maybe
doesn't even work. The reason for this is that processes from your
old session keeps hanging around. In fact, I was bitten by this just
before the holidays; I simply couldn't login. Why? An old gconfd
process was lingering and that blocked login. The solution? Log in
as root on VT1 and do the usual 'killall -9 -u davidz' dance.
The latter problem is, I think, on the level of being a security bug.
The former is just hindering process and is making people build on top
of our platform (speaking in upstream sense here) do really crackful
things like rewriting your .gnupg/gpg.conf file.
I think with a little work we could fix this on the X11 level and
potentially get this upstream too. First, in Fedora we actually got a
rather decent way of solving 1.; see
for the solution. Unfortunately, this a) isn't upstream; and b) isn't as
perfect as it needs to be. If you follow the flow, basically this
sets up SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION
does some weird stuff, then evals three variables above and,
essentially, execs gnome-session or startkde
a. Ideally SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION would just
use /etc/X11/xinit/xinitrc.d/. I'm told this is to make sure
things are reaped (because of problem 2. above)
b. It's annoying that the session bus is started after the stuff
in /etc/X11/xinit/xinitrc.d/ - no session bus for you.
c. No way to run code once the session is over.
Assuming problem 2. will be magically solved for us (see below), we
could nicely rearrange the flow such that SSH_AGENT, DBUS_LAUNCH,
CK_XINIT_SESSION could just use standard constructs
Another observation is that only stuff using environment variables
should use /etc/X11/xinit/xinitrc.d/ (some man page should spell this
out) - everything else should use the XDG autostart spec (where we have
UI, e.g. gnome-session-properties).
Also, since we're talking about environment variables, we surely need to
care about the ordering; e.g. we want
and so forth. Again, the man page should be clear about this. Also,
there should be a README file in /etc/X11/xinit/xinitrc.d/ that points
to the man page.
Instead of exec'ing gnome-session, we run it in the background. When we
are done we run the same scripts in reverse just with 'stop' instead of
'start' as the first positional parameter.
Notably, 00-ck-xinit-session.sh will take care of problem 2. The way it
does this is because of the way that ConsoleKit works. It basically will
just kill all the processes where the uid and the environment variable
XDG_SESSION_COOKIE matches. First it tries SIGTERM. Then after a few
seconds, it moves on to SIGKILL (e.g. -9).
(of course, any process can unset XDG_SESSION_COOKIE and then fork and
that way linger on. But no sane process would do that unless it's
All of this only includes modifying xorg-x11-xinit. We surely should get
- Things like seahorse-agent, ssh-agent and so forth now has proper
infrastructure to use. If we make the docs good enough we can point
people to these and hopefully people won't do horrendous things like
e.g. rewriting .gnupg/gpg.conf.
- We solve the decade-long problem of lingering processes after logout.
I think this is a pretty small project that could be done in a few days,
maybe a week. Any takers? Thoughts? Am I on crack?
Fedora-desktop-list mailing list
|All times are GMT. The time now is 02:17 PM.|
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.