User: Password:
Subscribe / Log in / New account

Upstart for user sessions needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

By Nathan Willis
April 17, 2013

Ubuntu has announced plans to use Upstart, its event-driven init replacement, to manage the desktop user session as well. The functionality will be available starting with the 13.04 release, but it will be disabled by default. The plan is to complete the transition in time for the Ubuntu 13.10 release. Upstart works by executing actions in response to events or signals emitted when there are changes in system state. The goal of the change is to migrate many of the desktop session's processes to be on-demand services, thus saving memory and power currently used to keep idle services running persistently.

Upstart maintainer James Hunt wrote about the change on his blog in April, although the nucleus of the idea goes back further than that. In October 2012, Didier Roche suggested eliminating long-running daemons as a way to reduce memory footprint. Ted Gould replied that the idea of using Upstart to replace some of these daemons had been floated for the Ubuntu 12.10 release, but was not pursued.

What's a session, anyway?

Currently, an Ubuntu desktop session starts when the display manager LightDM launches gnome-session in response to a successful login attempt. The window manager, panel, and other basic components are defined by a file in /usr/share/gnome-session/sessions/, but there are multiple other mechanisms through which the auxiliary programs that round out a full desktop session (such as system monitors, panel applets, and notification daemons for the network, Bluetooth, printers, and so forth) can be started. LightDM can be configured to run scripts, and the user can define startup applications through the GNOME preferences. But the bulk of the auxiliary programs auto-started for a session are defined in /etc/xdg/autostart/; on the Ubuntu 12.04 system I explored, there are 33 auxiliary programs, from AT-SPI to Zeitgeist. The rationale for introducing Upstart to this equation is that many of the persistent daemons listed /etc/xdg/autostart/ are merely watching for file changes or DConf configuration-key changes.

Early on, Upstart supported only event types needed for system initialization, such as filesystem mounting, network startup, run-level changes, and so forth. But recent releases have extended the set of supported events in order to facilitate managing desktop session tasks. In particular, version 1.7 introduced upstart-event-bridge, which relays system-level events down to the user session (thus allowing the desktop session to react to system-level events), and version 1.8 introduced upstart-file-bridge, which allows jobs to react to file changes (including file creation, deletion, modification, or anything else supported by inotify).

Upstart 1.3 had already introduced the notion of "User Jobs"—unprivileged jobs handled by Upstart and limited to a user's login session. Having Upstart manage the entire user session is an extension of this earlier functionality, which is now being renamed "Session Jobs." As Hunt explains in his post, the initial targets for migration to Upstart are programs like update-notifier. The update-notifier daemon watches for newly available package updates by monitoring a fixed set of filesystem locations in /var/ and watching for the insertion of removable media containing software packages.

update-notifier does seem to be ripe for conversion to an on-demand service; inserting a CD or DVD can be detected through D-Bus events, and the upstart-file-bridge can emit an event upon changes to the filesystem locations it monitors. These locations include /var/lib/update-notifier/user.d/, which the separate update-manager modifies whenever it finds a new package in one of the enabled package repositories. Querying those package repositories is a relatively infrequent event, a few times a day might even be considered overkill.

The same could be said for the network manager daemon (since few people change networks more than a few times per day), backup manager, and several of the other persistent processes. But there are others that one might expect to be responding to events frequently, such as the Orca screen reader or the Gwibber communication server. Consequently, the full memory and power savings of moving to Upstart's on-demand daemon model is a bit hard to quantify, but it is almost certainly non-zero.

Changes to Ubuntu

Hunt does not go into detail regarding what other services might migrate soon (although he mentions the crash reporter "whoopsie" as one possibility)—he spends most of the rest of the post explaining how to write Upstart jobs. But there is a blueprint on the distribution's wiki that describes more of the plan.

The existing Upstart init process will remain unchanged, running as PID 1. When the user session starts, Upstart will launch a child process with init --user. This child process will handle the session startup duties, receiving signals from the system init process through upstart-event-bridge. Apart from emitting those signals, the system init has no knowledge of the session init's activity.

The session init does need to listen for SIGCHLD signals from the daemons that it launches, however, so it can detect when those daemons exit. The design is currently to use the PR_SET_CHILD_SUBREAPER process control option, so that the session init remains the parent of any double-forking daemons it launches. The downside is that this option is Linux only, and that it may necessitate rewrites of some daemons that expect to run as the child of PID 1.

The presence of both system and session init processes has also necessitated some changes to Upstart's event naming scheme. System events are now prefixed with :sys:, so custom jobs will need to be rewritten, and the new syntax will need to be used from the command-line utilities (such as initctl).

Further out, of course, there are many more changes slated to come to Ubuntu desktop sessions, starting with the Mir display server and Unity Next environment. Ultimately, Mir and Unity Next will replace LightDM as the display manager. Before that time, though, migrating away from gnome-session might be viewed by critics as the distribution further diverging its system configuration from that of its contemporaries.

It will be interesting to see whether Chrome OS (the largest non-Ubuntu-related distribution to use Upstart) also shows interest in using Upstart for session management. It is not likely to look appealing to Systemd-based distributions of course, although the notion of an init system expanding to assume control over other parts of the system stack might sound familiar.

On that point, GNOME 3.8 is the first GNOME release to support Systemd as an option, so when the next development cycle completes for those distributions that use GNOME Shell, gnome-session could be slated for replacement on those systems as well. If that does happen, it will offer an opportunity to compare raw numbers for the two init replacements on session management tasks. The predicted change for Ubuntu users is that an Upstart-based session will have few daemons running, consuming less power (precious battery power on mobile systems) and less RAM. How the actual statistics play out will no doubt depend on a lot of factors, both on its performance against gnome-session and its inevitable comparison to Systemd.

(Log in to post comments)


Posted Apr 18, 2013 7:49 UTC (Thu) by ovitters (subscriber, #27950) [Link]

As mentioned on, the name of systemd is systemd, not any other variation, including "Systemd".

I don't understand why it is suggested that GNOME 3.8 is the first release to optionally make use of systemd, we already had that. This allowed the deprecation of ConsoleKit and others.

What this article is about is something different, making use of user login sessions. That would be a nice change (hopefully getting rid of gnome-session), but there is nothing in GNOME 3.8 that makes that a special release for that. Not having fallback mode makes things easier (can move functionality across components), but that's not that special IMO.

IMO from a maintenance POV it would be nice to just push all the -session related bits towards systemd. Then have systemd provide the shared functionality (gnome-session, KDE version of it, etc) across desktop environments. I talked very briefly about this with someone from Enlightment projest, and they were positive about this as well. Though IIRC that discussion was in #systemd, so... ;)

Obviously we're aware of *BSD and non-systemd using distributions. Personally I'd suggest those non-systemd distributions to switch already :P


Posted Apr 18, 2013 9:06 UTC (Thu) by kugel (subscriber, #70540) [Link]

You're not "obviously aware" as systemd doesn't even work on *BSD, so switching is not an option.


Posted Apr 18, 2013 10:04 UTC (Thu) by khim (subscriber, #9252) [Link]

AFAIK systemd exposes it's functionality over dbus. Thus it should be possible to implement the required functionality on *BSD or in upstart.


Posted Apr 18, 2013 10:19 UTC (Thu) by ovitters (subscriber, #27950) [Link]

That is not always easily possible. E.g. the API in some cases expose Linux-specific things like cgroups. Not sure if that is the case for user login bits.

The reason nobody pushed much for this user login using systemd is due to *BSD and non-systemd using distributions. Though there are big benefits to minimize the amount of code that is maintained. If all these bits are shared across desktop environments and standardized, it obviously makes things easier, more consistent, more features and less buggy. Though it takes time of course.

Personally I don't see any value in having different code paths for this. Just makes things more buggy and I don't understand the benefit. But as said, reality at the moment is *BSD and non-systemd distributions.


Posted Apr 18, 2013 10:10 UTC (Thu) by ovitters (subscriber, #27950) [Link]

What should've been dead obvious to anyone except you is that we're obviously aware that systemd does not run on *BSD, nor does it run on distributions which do not use systemd.

Maybe you think *BSD is a distribution?!? Obviously that is not the case.


Posted Apr 18, 2013 10:45 UTC (Thu) by Seegras (guest, #20463) [Link]

Of course, there are different *BSD distributions. FreeBSD, PC-BSD, pfSense, Debian kFreeBSD and so on, all different FreeBSD distributions. And then the forked ones, like NetBSD and OpenBSD of which there are also different distributions.

And systemd might even run on Debian/kFreeBSD ;)


Posted Apr 18, 2013 11:28 UTC (Thu) by ovitters (subscriber, #27950) [Link]

I've never seen anyone mean anything other than Linux distributions when referring to distributions. I think my comment was quite clear and that initial suggestion that me/GNOME would not be aware that systemd does not run on *BSD the way it was phrased (so not your comment) is just stupid and was not needed.

Forked *BSDs

Posted Apr 18, 2013 22:51 UTC (Thu) by pjtait (subscriber, #17475) [Link]

Isn't FreeBSD just as much a fork of 386BSD as NetBSD?


Posted Apr 25, 2013 21:05 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> And systemd might even run on Debian/kFreeBSD ;)
No, it requires a Linux kernel.


Posted Apr 18, 2013 12:06 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

The D makes me think so.

(I kept the title just to have one more instance of the spelling you disapproved of. I looked at the page you linked to and it said nothing against that spelling)

Anyway, this article was about Upstart. Interesting to see it developed (and used in more than one distribution).

upstart again

Posted Apr 18, 2013 21:50 UTC (Thu) by jubal (subscriber, #67202) [Link]

…well, considering that upstart is being used by both Ubuntu and ChromeOS (I'm not counting RHEL6/CentOS6 because its use there is temporary), it might be possible that there are more systems that are using upstart than systemd.

upstart again

Posted Apr 18, 2013 22:44 UTC (Thu) by intgr (subscriber, #39733) [Link]

> there are more systems that are using upstart than systemd.

Quick, systemd fans, we need your help to win this competition! In a crowdsourced manner

A Linux systemd virtual machine can boot with about 30 MB of memory. This means a machine with 8 GB memory can launch a whopping 250 systemd virtual machines.

You can run the virtual machines at night when you're not using your computer and stop them when doing actual work. Work is underway to develop a systemd@Home screensaver application that will automate this process.

upstart again

Posted Apr 19, 2013 2:46 UTC (Fri) by zuki (subscriber, #41808) [Link]

Nah, VMs are so last year. systemd-spawn Fedora 19 container with systemd running as init in the container boots in about 40ms and has a PID-count about 30, and uses a few megabytes of RSS. And you can run as many as you want from a shared filesystem, so it's much easier to meet the quota :)

upstart again

Posted Apr 19, 2013 3:04 UTC (Fri) by apoelstra (subscriber, #75205) [Link]

This has been the plot of several movies now, please be careful...

upstart again

Posted Apr 20, 2013 20:35 UTC (Sat) by nix (subscriber, #2304) [Link]

All recent Kindles (v3 or later at least) use upstart too. That adds a good few tens of millions of upstart instances. I think upstart wins. :)

(btw, similarly, awesome is a very popular window manager... among people who have no idea that their e-reader is running a window manager or even what one is.)

Environment variables?

Posted Apr 23, 2013 8:52 UTC (Tue) by Yenya (subscriber, #52846) [Link]

I know environment variables are soooo 1990s, but let me ask anyway: how are upstart-managed sessions and their services supposed to inherit the localization settings, path to the SSH agent socket, etc.?

Environment variables?

Posted Apr 23, 2013 19:47 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Any services which would normally export environment variables would have to inform upstart of the new variables (and remove them if and when the service is stopped). This is how systemd does it for user sessions at least.

Environment variables?

Posted Apr 25, 2013 15:25 UTC (Thu) by grawity (subscriber, #80596) [Link]

Current GNOME handles environment variables the same way too (gnome-session starts gnome-keyring, which asks gnome-session to set $GPG_AGENT_INFO).

Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds