At the 2011 Linux Plumbers Conference, it was not entirely unusual to hear
complaints that the sessions were not as energetic and discussion-oriented
as they were in previous LPCs.
Chances are good that anybody talking that way did not attend the "Boot and
Init" session, which was an occasion for vigorous - if good-natured -
debate. This article will cover two of the topics discussed there: booting
the system and the init process.
Reworking the boot sequence
According to Harald Hoyer, Linux does not lack for available boot loaders;
indeed, we have far too many of them. These boot loaders are becoming more
complex in unwelcome ways. GRUB and GRUB2, for example, contain
reimplementations of a number of filesystems used in Linux. GRUB
developers work hard to keep up, but they often find themselves one step
behind what is being done in the kernel. GRUB2 has made things worse by
turning its configuration file into a general-purpose scripting language;
that adds a bunch of complexity to the bootstrap process. We also see
battles between distributions (and non-Linux operating systems) over who
controls the master boot record (MBR) on the disk.
Harald had a proposal for improving the situation: rather than add
complexity to boot loaders in an attempt to keep up with the kernel, why
not just boot a simple generic Linux kernel and let it deal with the rest?
His idea is to create a /firstboot directory with a simple
filesystem and populate it with a single Linux kernel and an initramfs
image whose sole purpose is to find the real kernel and boot that.
This kernel will naturally understand Linux filesystems, and it will
support a user space with enough power to run whatever scripts are needed
to find other bootable images on the system. Meanwhile, the initial boot
loader can be made to be as simple as possible and distributions can stop
messing with the MBR.
The idea has some clear appeal, but it was not universally accepted by the
others in the room. To many, it looks like trying to solve the boot
problem by adding an extra level of indirection. In the process, it adds
another kernel bootstrap which, in turn, will make the boot process longer
and, arguably, more likely to fail. It is safe to say that no consensus
was reached in the room; the work will presumably continue and will be
judged on its merits when it is more advanced.
The bulk of the time in this session was spent discussing Systemd. Lennart
Poettering talked at length about what has been accomplished in the last
year and where Systemd can be expected to go in the future. Suffice to say
that, as always, he does not lack ambition or a willingness to
stir things up.
In the last year, Lennart said, we have seen the first release of a
distribution using Systemd by default - Fedora 15. Mandriva has
recently released a Systemd-based version, and others (including openSUSE and
"a couple of others") are in the works. He seemed well pleased with the
adoption of Systemd so far.
Systemd is now able to boot a system without invoking any shells at all.
Under "ideal circumstances" it can get to a running user space less than
one second after startup. Not everybody gets to run under ideal
circumstances; the goal for the rest of us is less than ten seconds. There
are some significant challenges in the way of getting there, though; for
example, just loading the SELinux policy can take a few seconds by itself.
Starting up the logical volume manager (LVM) can also take a while; Lennart
proposes to fix that one by just removing LVM and using the volume
management features in Btrfs instead.
Lennart paused here to make the point that Systemd is now a capable init
system. But that's not where it stops; the plan is for Systemd to be a
platform on which a number of interesting things can be built.
There was a bit of discussion over moving functionality into Systemd. For
example, not everybody is happy with moving the setting of the host name
into the program. Lennart's position is that this task is done with a
single system call; invoking a separate binary for that just isn't
worthwhile. Others disagreed with this assessment. There was similar
disagreement over setting the system clock directly instead of using
hwclock; once again Lennart thinks it is too simple a task to
require a separate program, especially one as filled with legacy cruft as
hwclock is. Scott James Remnant asserted that said cruft is what
makes hwclock actually work for all systems and asked whether
Lennart planned to refuse to support older machines. Lennart's response
older hardware is fine; what he is not supporting is older kernels that
lack proper realtime clock drivers.
In general, though, he said that, while Systemd is trying to simplify
common initialization tasks and make them fast, there is nothing preventing
people from using external programs like hwclock if that is what
they want to do. Systemd carefully avoids taking away the ability to use
older tools if that's what's needed. When those tools are not necessary,
though, Systemd aims to be able to completely boot a system with only a
very small number of other packages (such as glibc, d-bus, and util-linux)
installed. In the process, he hopes to standardize the boot process across
distributions, getting rid of lots of little differences that do not need
to be there.
A moment was spent defending Systemd against the charge of being bloated.
It is not bigger than it needs to be, Lennart said, and embedded developers
can use configuration options to trim it down considerably if there is
functionality that they do not want. Systemd is being picked up by
embedded distributions like Yocto and Ångström.
There are a number of interesting changes coming into Systemd in the near
future. One of those is the elimination of getty processes at
startup time. Instead, Systemd will start a getty on demand if
and when the user switches to a virtual console. The user experience will
be the same, but there will be fewer processes cluttering the system.
All services started by Systemd will have their standard output and error
streams connected to syslog by default. That makes it easier to write
services; it even supports the severity notation used by printk()
in the kernel. The downside is that verbose processes can clog the system
log, but, Lennart said, that should be fixed by shutting those processes
"Presets" are another upcoming feature. Each distribution has its own
policy regarding whether services should be started by default and where
the exceptions are. Fedora, for example, requires explicit administrator
action to start any service, while Debian tends to assume that, if a
service is installed, it is meant to be run. The preset feature allows the
distributor to encapsulate that policy in a single file outside of the
packages for those services. Spins or derivative distributions can use it
to create a different policy without needing to modify the packages
themselves, and administrators can impose their own policy if they wish.
Further in the future is the idea of using systemd to manage sessions. The
problems encountered at that level, he said, are quite similar to those
encountered at initialization time. It's really just a matter of starting
a set of programs and keeping track of them. He had hoped to have session
management ready for Fedora 16, but that didn't happen, so the current
target is Fedora 17.
As part of this work, Lennart would really like the kernel to present a
single view of an "application," which can involve any number of processes.
For example, it would be nice to give specific applications access to
certain ports through the firewall. Control groups handle this task
reasonably well, so that is what Systemd is using. He is also trying to
create a unified view of a "session" encompassing its control group,
desktop, login information, PAM credentials, etc.
Specific goals for Fedora 17 include finishing this user session work.
There should also be multi-seat support. Imagine plugging in a USB hub
with keyboard, mouse, audio port, and frame buffer device; Systemd will
pick it up,
start a GDM session, and all of it will just work with no configuration
work required at all. This feature will be nice for settings like schools
where one system can easily handle multiple users; he also noted that it
can be highly useful for debugging embedded systems. Once upon a time, all
Unix systems were multi-seat; he is, he said, just bringing back a feature
that was in Unix at the very beginning. One side effect of this work will
be the removal of ConsoleKit.
There was some talk of removing the cron daemon, but that seems
unlikely to happen. What may happen instead is a movement of all the standard
system cron jobs to Systemd with the result that cron becomes an optional
utility. There was some interesting talk of using wakeup timers to set up
jobs that can actually power up the system to run. But cron
itself is a useful tool with a nice-enough interface; there doesn't seem to
be any real reason to replace it. But it will probably only be started if
actual configuration files are found.
Finally, there was a bit of talk about Systemd's socket activation
mechanism and security. Evidently "the SELinux folks" (not named in the
discussion) do not like this feature because Systemd represents a third,
uncontrolled process in
the connection between client and server. But Lennart pointed out that
Systemd never reads data from sockets; it simply uses them in the
activation process. And, in any case, Systemd is charged with loading the
SELinux policy in the first place; if it cannot be trusted, the system has
The overall picture was of a project that is on a roll, gaining features
and users at a fast rate. The Systemd view of the world has not yet won
over everybody, but the opposition seems to be fading. Systemd looks like
the init system of the future (and more) for a lot of high-profile
to post comments)