What’s New in systemd, 2015 Edition

Profile image of Mattias Geniar

Mattias Geniar, February 01, 2015

Follow me on Twitter as @mattiasgeniar

This post is part of a series of notes I’ve taken at FOSDEM 2015 in Brussels, Belgium. If you’re interested, have a look at the other posts.

A packed room at Fosdem for Lennart Poettering’s talk on systemd, the 2015 edition.

systemd is now a core component of most major distributions. In this talk I want to give an overview over everything new in the systemd project over the last year, and what to expect over the next year.

fosdem talk description

There were no slides. None whatsoever. No presentation. He just talked.

lennart_systemd_fosdem_2015

Notes are scribbled down really quickly, so errors may occur. Don’t quote this directly. If you spot any errors, please let me know. ;-)

Video available

The video recording of the talk is now available online. Someone was kind of enough to mirror this on YouTube – I’m not sure if this is allowed by Fosdem, but for the time being I’ll embed it here.

If you’re not interested in the video, the talk is written down below!

Transcript

  • user space components in systemd for dbus are mostly done (new library for C developers)
  • nspawn (a minimal container manager) was originally made to test the init-system, without rebooting the box every time (for testing systemd development). It grew over time to a viable (minimal) container manager. Supports RAW images and docker-like containers.
  • machined: a virtual machine registration manager, takes inspiration from Solaris’ “zone” concept
  • in general: more container features are to be expected
  • the goal is have all tools be “container” aware, so journald can show the logs/messages from the host as well as all the containers running on it
  • next version (released in ~2 weeks) of systemd will have additional btrfs support
  • minimal firewall support, which is service oriented. Ie: allow Apache access in the firewall instead of saying “allow port :80” access. Gives better support for the variety of ports services can listen on. Would also prevent port-hijacking from other services, since it’s bound to the service.
  • consoled: support for high DPI screens and unicode
  • systemctl-cat, systemctl-edit: cat the config file of the unit you specify, so you don’t need to know the path on the system (ie: systemctl-cat apache2.service). The systemctl-edit apache2.service immediately opens the unit file to edit. After a save, the service can get reloaded automatically.
  • nss-getmyhostname: a function call to get the local hostname, in case /etc/* is entirely empty (for stateless hosts).

fosdem_2015_systemd_room

Part deux

  • ping gateway: automatically resolve the gateway of all interfaces and ping them, very useful for network troubleshooting and the question “am I online?". The “ping gateway” gets resolved automatically (so you actually type ping gateway at the CLI).
  • networkd: because networking is such a basic function of the OS, he believes it should be in systemd
  • networkd: systemd wrote their own dhcp library (compatible with dhcpv4 and dhcpv6)
  • combining nspawn (containers) and networkd (dhcp) allows for easier network management of containers. Networkd can also run inside the container. Outside the container networkd can pick a free DHCP IP for that container. Allows v4 to v6 network masquarading automatically. Does not involve dnsmasq, everything is routed via IP on the kernel (no bridging).
  • auditing: implemented for when your application needs to be NSA approved (that appeared to be the main reason, Lennart himself said he’s not a big fan of it). Can log all system calls made to /etc/passwd etc to the audit log. Auditing is integrated with journald, audit-tools to read the logs have been improved.
  • Linux distributions are moving to “stateless” systems, with only /usr content available/writable. If /etc/ and /var are unpopulated, the system (systemd) will do the minimal bits to boot up the system. Only your own changes would make it to /etc. systemd adds better support for these kind of setups.
  • resolved: adds support for multiple resolving (use case: connected to a remote VPN which then loses the local DNS resolving). A request can be sent to every interface in checking for a response. Resolvd maintains a DNS cache per interface. Adds support for LLMNR (link
    • local multi
      • cast nameserver resolution, used by Windows). Resolvd was recently discovered to be vulnerable to a DNS cache poisoning attack.

      • journald-remoting: the binary logger now has remote support (aka: remoting) via HTTP (instead of the syslog protocol, which isn’t standardized (ie: no timezones, single-line logs only, …)). Journald has a pull and push model. Pull = HTTP GET request for a JSON stream. Push model pushes via the HTTP POST request to a remote journald instance. Allows for “simple” implementations of programs (PHP, Ruby, …) to send data to a remote journald endpoint, since it’s just HTTP POST. Could replace syslogging.

      • service management: can set up minimal namespaces for services (ie: marking /usr or /home read-only for that particular service).

        • Configured in the init files. Minimal sandboxing/chrooting.
        • Can also hide partitions instead of making them just read only. For instance, if /home is “hidden” it will appear as an empty directory.
        • Can also give a private /tmp to each service, so no longer a server-shared /tmp directory that everyone can access. This uses subdirectories in /tmp (so you still have partition control over /tmp) but it’s separated from the other services.
        • Can also hide /dev/* devices and hide all the physical devices (like /dev/sda, …) and only keep /dev/zero, /dev/null, … for particular services.
        • By using other systemd tools (not mentioned), you can limit access to /dev/* devices to particular services and block it for all others
        • timesyncd: the idea is to not run an ntpd on every device anymore. timesyncd is a trivial ntp client (not a server!), a simple as possible. Integrates with networkd (networkd learns the ntpd servers and passes them on to timesyncd). This is also needed for stateless machines without an /etc/* directory, which at boot would not have a notion of time.
        • GPT (GUID Partition Table) auto-discovery: since /etc/fstab can be absent on stateless systems. Auto-discovery of the GPT is very nice. Discovers swap devices (since it has a very distinct UUID in the GPT) and root partitions, even without the /etc/fstab configs.
        • read ahead implementation dropped: in the age of SSDs the benefit is not big enough to have this. All systemd developers have SSDs and no more spinning disks, nobody could/wanted to support this anymore. The idea was to read-ahead the bits needed during the boot process and remember it next time, for faster boots. But with SSDs, this support is dropped.
        • a new secure boot implementation: this is a work-in-progress, to have more validation of the boot process that it hasn’t been tampered with. It will integrate a new method of signing images and initrd’s.

      Update

      Updated for correctness:

      State retention

      systemd will add support for restarting services without losing state. Every daemon will store a minimal system state on disk, so if it’s restarted it can resume the original state. This will allow daemons to restart themselves without harm. Lately, journald has received support for this as well.

      This concept builds further upon the socket activation. When restarting a service, systemd can push the used sockets/file descriptors of that service to the sytemd daemon and pass it again to the service once it restarted. This way, no sockets/fd’s are lost.

      Key takeways: most of what is in systemd is optional (except for journald). If there are parts you don’t like or disagree with, you can just not use it. Documentation is being worked on and is considered a priority in the systemd project.

      If you’re interested, I have another post on resources for learning systemd you may find interesting. It also has some interesting comments.

      Update 3/2/2015: I’ve removed some truly offending comments. I do not approve of hate and threat on this blog. You are free to discuss the pro’s/cons of systemd – but any form of threat against anyone’s life will be deleted straight away, no matter if it’s meant as a “joke”.



Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.