It has been a while since my original
announcement of systemd. Here's a little status update, on what
happened since then. For simplicity's sake I'll just list here what we
worked on in a bulleted list, with no particular order and without
trying to cover this comprehensively:
- systemd has been accepted as Feature for Fedora 14, and as it
looks right now everything worked out nicely and we'll ship F14 with
systemd as init system.
- We added a number of additional unit types: .timer for
cron-style timer-based activation of services, .swap exposes
swap files and partitions the same way we handle mount points, and
.path can be used to activate units dependending on the
existance/creation of files or fill status of spool directories.
- We hooked systemd up to SELinux: systemd is now capabale of
properly labelling directories, sockets and FIFOs it creates according
to the SELinux policy for the services we maintain.
- We hooked systemd up to the Linux auditing subsystem: as first
init system at all systemd now generates auditing records for all
services it starts/stops, including their failure status.
- We hooked systemd up to TCP wrappers, for all socket connections
it accepts.
- We hooked systemd up to PAM, so that optionally, when systemd runs
a service as a different user it initializes the usual PAM session
setup and teardown hooks.
- We hooked systemd up to D-Bus, so that D-Bus passes activation
requests to systemd and systemd becomes the central point for all
kinds of activation, thus greatly extending the control of the
execution environment of bus activated services, and making them
accessible through the same utilities as SysV services. Also, this
enables us to do race-free parallelized start-up for D-Bus services
and their clients, thus speeding up things even further.
- systemd is now able to handle various Debian and OpenSUSE-specific
extensions to the classic SysV init script formats natively, on top of
the Fedora extensions we already parse.
- The D-Bus coverage of the systemd interface is now complete,
allowing both introspection of runtime data and of parsed
configuration data. It's fun now to introspect systemd with gdbus
or d-feet.
- We added a systemd
PAM module, which assigns the processes of each user session to
its own cgroup in the systemd cgroup tree. This also enables reliable
killing of all processes associated with a session when the user logs
out. This also manages a secure per-user /var/run-style directory
which is supposed to be used for sockets and similar files that shall
be cleaned up when the user logs out.
- There's a new tool systemd-cgls,
which plots a pretty process tree based on the systemd cgroup
hierarchy. It's really pretty. Try it!
- We now have our own cgroup hierarchy beneath
/cgroup/systemd (though is will move to /sys/fs/
before the F14 release).
- We have pretty code that automatically spawns a getty on a serial
port when the kernel console is redirected to a serial TTY.
- systemctl got beefed up substantially (it can even draw
dependency graphs now, via dot!), and the SysV compatiblity
tools were extended to more completely and correctly support what was
historically provided by SysV. For example, we'll now warn the user
when systemd service files have changed but systemd was not asked to
reload its configuration. Also, you can now use systemd's native
client tools to reboot or shut-down an Upstart or sysvinit system, to
facilitate upgrades.
- We provide a reference
implementation for the socket activation and other APIs for nicer
interaction with systemd.
- We have a pretty complete set of documentation
now, some
of it even extending to areas not directly related to systemd
itself.
- Quite a number of upstream packages now ship with systemd service
files out-of-the-box now, that work across all distributions that have
adopted systemd. It is our intention to unify the boot and service
management between distributions with systemd, and this shows fruits
already. Furthermore a number of upstream packages now ship our
patches for socket-based activation.
- Even more options that control the process execution environment
or the sockets we create are now supported.
- Earlier today I began my series of blog stories on systemd
for administrators.
- We reimplemented almost all boot-up and shutdown scripts of the
standard Fedora install in much smaller, simpler and faster C
utilities, or in systemd itself. Most of this will not be enabled in
F14 however, even though it is shipped with systemd upstream. With
this enabled the entire Linux system gains a completely new feeling as
the number of shells we spawn approaches zero, and the PID of the
first user terminal is way < 500 now, and the early boot-up is
fully parallelized. We looked at the boot scripts of Fedora, OpenSUSE
and Debian and distilled from this a list of functionality that makes
up the early boot process and reimplemented this in C, if possible
following the bahaviour of one of the existing implementations from
these three distributions. This turned out to be much less effort than
anticipated, and we are actually quite excited about this. Look
forward to the fruits of this work in F15, when we might be able to
present you a shell-less boot at least for standard desktop/laptop
systems.
- We spent some time reinvestigating the current syslog logic, and
came up with an elegant and simple scheme to provide /dev/log
compatible logging right from the time systemd is first initialized
right until the time the kernel halts the machine. Through the wonders
of socket based activation we first connect the /dev/log
socket with a minimal bridge to the kernel log buffer (kmsg)
and then, as soon as the real syslog is started up as part of the
later bootup phase, we dynamically replace this minimal bridge by the
real syslog daemon -- without losing a single log message. Since one
of the first things the real syslog daemon does is flushing the kernel
log buffer into log files, all logged messages will sooner or later be
stored on disk, regardless whether they have been generated during
early boot, late boot or system runtime. On top of that if the syslog
daemon terminates or is shut down during runtime, the bridge becomes
active again and log output is written to kmsg again. The same applies
when the system goes down. This provides a simple an robust way how we
can ensure that no logs will ever be lost again, and logging is
available from the beginning of boot-up to the end of
shut-down. Plymouth will most likely adopt a similar scheme for initrd
logging, thus ensuring that everything ever logged on the system will
properly end up in the log files, whether it comes from the kernel,
from the initrd, from early-boot, from runtime or shutdown. And if
syslogd is not around, dmesg will provide you with access to
the log messages. While this bridge is part of systemd upstream, we'll
most likely enable this bridge in Fedora only starting with F15. Also
note that embedded systems that have no interest in shipping a full
syslogd solution can simply use this syslog bridge during the entire
runtime, and thus making the kernel log buffer the centralized log
storage, with all the advantages this offers: zero disk IO at runtime,
access to serial and netconsole logging, and remote debug access to
the kernel log buffer.
- We now install autofs units for many "API" kernel virtual file
systems by default, such as binfmt_misc or
hugetlbfs. That means that the file system access is readily
available, client code no longer has to manually load the respective
kernel modules, as they are autoloaded on first access of the file
system. This has many advantages: it is not only faster to set up
during boot, but also simpler for applications, as they can just
assume the functionality is available. On top of that permission
problems for the initialization go away, since manual module loading
requires root privileges.
- Many smaller fixes and enhancements, all across the board, which
if mentioned here would make this blog story another blog
novel. Suffice to say, we did a lot of polishing to ready systemd for
F14.
All in all, systemd is progressing nicely, and the features we have
been working on in the last months are without exception features not
existing in any other of the init systems available on Linux and our
feature set already was far ahead of what the older init
implementations provide. And we have quite a bit planned for the
future. So, stay tuned!
Also note that I'll speak about systemd at LinuxKongress
2010 in Nuremberg, Germany. Later this year I'll also be speaking
at the Linux
Plumbers Conference in Boston, MA. Make sure to drop by if you
want to learn about systemd or discuss exiciting new ideas or features
with us.
posted at: 13:32 | path: /projects | permanent link to this entry | 64 comments
RSS 0.91, RSS 2.0