I’ve been working on this as a project for a little while now, and it’s getting to a reasonably usable state, so I thought I’d write about it in public.

What?

When you fire up your machine and see GDM’s friendly face smiling back at you, how did it get there? Clearly it was executed, but by what? The short answer is that GDM asked gnome-session to start its UI up for you.

What you see is GNOME Shell started up in a special mode, which it was asked to do by being started in an environment where GNOME_SHELL_SESSION_MODE=gdm. Behind the scenes gnome-session also started a load of session services from the given XDG autostart directories, which gives you gnome-settings-daemon amongst other things. These services can specify at what “phase” they are started at – look for X-GNOME-Autostart-Phase in /etc/xdg/autostart/*.desktop to see this – which gives a form of ordering. The session specifies a bunch of required components, and gnome-session makes sure that these are all running before the session can be considered fully started. If any of them don’t start up, the session has failed to start. Much the same thing exists for the user session too.

Hmm… this is ringing some bells…

Why?

This is quite a crude dependency mechanism. While there are some mechanisms to add extra conditions to autostart services, such as only if a certain file exists or a GSettings key is set, we now (this is not actually a new idea; the bug for this problem was filed in 2012) have a much better way of starting programs when they are needed. That’s systemd of course. If the session needs program X, and program Y needs program X, we can express this. If X isn’t ready until it claims a name on the bus, we can express that too. Restarting things on failure, executing programs at a specified time (alarms), the list goes on.

We already use this stuff for system services in fact, so why not for user ones? If starting a session is essentially executing a bunch of programs at the right time, and we have a utility to execute things in a more flexible way – why not join the two together?

A year or two ago some of us from Ubuntu sat down and worked up an implementation of this for the Unity session we were using back then. We in fact shipped 16.10 (yakkety) with this scheme in place. Since we’re now using GNOME Shell in Ubuntu – and because it’s the right thing to do anyway – it’s time to start working on getting this upstream. Credit goes to Martin Pitt and Sebastien Bacher for the work back then which we’re building on now.

Where are we now?

I’ve got a bunch of patches that I’m starting this week to push to maintainers for review. Most of these are prerequisites for transitioning sessions to be started in this way, but are not harmful when the current method is used either. They can be applied immediately. The actual switch is performed in two places – one to GDM to instruct gnome-session to launch a particular target, and the second to gnome-session to update the session definition files to launch targets instead of executing parts itself.

There is scope for further work here. My initial conversions don’t use particularly advanced features or dependencies. We could probably move more things out of the critical path and have them started on demand.

If you’re worrying about your third party session needing to be reworked for this, don’t be (yet). I’ve been quite careful so far to not require this scheme to be used, so non-GNOME sessions should continue to work as they do now. However, since gnome-session is now duplicating a lot of the same work that systemd is doing, it makes sense for us to talk about how we will go about removing this functionality in a future cycle, so that gnome-session becomes a much smaller thing.

I’ve written a wiki page with a few more technical details. This will be updated as patches are posted and merged.

Hmm, I guess this is kind of lame if you can’t try it. I should make a repository or something.