[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

   sources /etc/X11/xinit/xinitrc
     sources /etc/X11/xinit/xinitrc-common
       sources /etc/X11/xinit/xinitrc.d/*.sh
     does some weird stuff, then evals three variables above and,
      essentially, execs gnome-session or startkde


    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
in /etc/X11/xinit/xinitrc.d/. 

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
this upstream. 

The benefits?

- 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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]