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
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.
to post comments)