Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/systemd-update.html

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.