LWN.net Logo

systemd 183 released

From:  Lennart Poettering <lennart-AT-poettering.net>
To:  systemd Mailing List <systemd-devel-AT-lists.freedesktop.org>
Subject:  [ANNOUNCE] systemd 183
Date:  Fri, 25 May 2012 14:28:22 +0200
Message-ID:  <20120525122821.GA9569@tango.0pointer.de>
Archive-link:  Article, Thread

Heya,

http://www.freedesktop.org/software/systemd/systemd-183.t...

Note that this release is a major technology upgrade, and contains a lot
of new code you probably don't want to stick into your stable
distribution right-away. We expect this to stabilize over the next
handful of releases.

This release is already available in Fedora Rawhide.

From the NEWS file:

        * Note that we skipped 139 releases here in order to set the
          new version to something that is greater than both udev's
          and systemd's most recent version number.

        * udev: all udev sources are merged into the systemd source tree now.
          All future udev development will happen in the systemd tree. It
          is still fully supported to use the udev daemon and tools without
          systemd running, like in initramfs or other init systems. Building
          udev though, will require the *build* of the systemd tree, but
          udev can be properly *run* without systemd.

        * udev: /lib/udev/devices/ are not read anymore; systemd-tmpfiles
          should be used to create dead device nodes as workarounds for broken
          subsystems.

        * udev: RUN+="socket:..."  and udev_monitor_new_from_socket() is
          no longer supported. udev_monitor_new_from_netlink() needs to be
          used to subscribe to events.

        * udev: when udevd is started by systemd, processes which are left
          behind by forking them off of udev rules, are unconditionally cleaned
          up and killed now after the event handling has finished. Services or
          daemons must be started as systemd services. Services can be
          pulled-in by udev to get started, but they can no longer be directly
          forked by udev rules.

        * udev: the daemon binary is called systemd-udevd now and installed
          in /usr/lib/systemd/. Standalone builds or non-systemd systems need
          to adapt to that, create symlink, or rename the binary after building
          it.

        * libudev no longer provides these symbols:
            udev_monitor_from_socket()
            udev_queue_get_failed_list_entry()
            udev_get_{dev,sys,run}_path()
          The versions number was bumped and symbol versioning introduced.

        * systemd-loginctl and systemd-journalctl have been renamed
          to loginctl and journalctl to match systemctl.

        * The config files: /etc/systemd/systemd-logind.conf and
          /etc/systemd/systemd-journald.conf have been renamed to
          logind.conf and journald.conf. Package updates should rename
          the files to the new names on upgrade.

        * For almost all files the license is now LGPL2.1+, changed
          from the previous GPL2.0+. Exceptions are some minor stuff
          of udev (which will be changed to LGPL2.1 eventually, too),
          and the MIT licensed sd-daemon.[ch] library that is suitable
          to be used as drop-in files.

        * systemd and logind now handle system sleep states, in
          particulary suspending and hibernating.

        * logind now implements a sleep/shutdown/idle inhibiting logic
          suitable for a variety of uses. Soonishly Lennart will blog
          about this in more detail.

        * var-run.mount and var-lock.mount are no longer provided
          (which prevously bind mounted these directories to their new
          places). Distributions which have not converted these
          directories to symlinks should consider stealing these files
          from git history and add them downstream.

        * We introduced the Documentation= field for units and added
          this to all our shipped units. This is useful to make it
          easier to explore the boot and the purpose of the various
          units.

        * All smaller setup units (such as
          systemd-vconsole-setup.service) now detect properly if they
          are run in a container and are skipped when
          appropriate. This guarantees an entirely noise-free boot in
          Linux container environments such as systemd-nspawn.

        * A framework for implementing offline system updates is now
          integrated, for details see:
          http://freedesktop.org/wiki/Software/systemd/SystemUpdates

        * A new service type Type=idle is available now which helps us
          avoiding ugly interleaving of getty output and boot status
          messages.

        * There's now a system-wide CapabilityBoundingSet= option to
          globally reduce the set of capabilities for the
          system. This is useful to drop CAP_SYS_MKNOD, CAP_SYS_RAWIO,
          CAP_NET_RAW, CAP_SYS_MODULE, CAP_SYS_TIME, CAP_SYS_PTRACE or
          even CAP_NET_ADMIN system-wide for secure systems.

        * There are now system-wide DefaultLimitXXX= options to
          globally change the defaults of the various resource limits
          for all units started by PID 1.

        * Harald Hoyer's systemd test suite has been integrated into
          systemd which allows easy testing of systemd builds in qemu
          and nspawn. (This is really awesome! Ask us for details!)

        * The fstab parser is now implemented as generator, not inside
          of PID 1 anymore.

        * systemctl will now warn you if .mount units generated from
          /etc/fstab are out of date due to changes in fstab that
          haven't been read by systemd yet.

        * systemd is now suitable for usage in initrds. Dracut has
          already been updated to make use of this. With this in place
          initrds get a slight bit faster but primarily are much
          easier to introspect and debug since "systemctl status" in
          the host system can be used to introspect initrd services,
          and the journal from the initrd is kept around too.

        * systemd-delta has been added, a tool to explore differences
          between user/admin configuration and vendor defaults.

        * PrivateTmp= now affects both /tmp and /var/tmp.

        * Boot time status messages are now much prettier and feature
          proper english language. Booting up systemd has never been
          so sexy.

        * Read-ahead pack files now include the inode number of all
          files to pre-cache. When the inode changes the pre-caching
          is not attempted. This should be nicer to deal with updated
          packages which might result in changes of read-ahead
          patterns.

        * We now temporaritly lower the kernel's read_ahead_kb variable
          when collecting read-ahead data to ensure the kernel's
          built-in read-ahead does not add noise to our measurements
          of necessary blocks to pre-cache.

        * There's now RequiresMountsFor= to add automatic dependencies
          for all mounts necessary for a specific file system path.

        * MountAuto= and SwapAuto= have been removed from
          system.conf. Mounting file systems at boot has to take place
          in systemd now.

        * nspawn now learned a new switch --uuid= to set the machine
          ID on the command line.

        * nspawn now learned the -b switch to automatically search
          for an init system.

        * vt102 is now the default TERM for serial TTYs, upgraded from
          vt100.

        * systemd-logind now works on VT-less systems.

        * The build tree has been reorganized. The individual
          components now have directories of their own.

        * A new condition type ConditionPathIsReadWrite= is now available.

        * nspawn learned the new -C switch to create cgroups for the
          container in other hierarchies.

        * We now have support for hardware watchdogs, configurable in
          system.conf.

        * The scheduled shutdown logic now has a public API.

        * We now mount /tmp as tmpfs by default, but this can be
          masked and /etc/fstab can override it.

        * Since udisks doesn't make use of /media anymore we are not
          mounting a tmpfs on it anymore.

        * journalctl gained a new --local switch to only interleave
          locally generated journal files.

        * We can now load the IMA policy at boot automatically.

        * The GTK tools have been split off into a systemd-ui.

        Contributions from: Andreas Schwab, Auke Kok, Ayan George,
        Colin Guthrie, Daniel Mack, Dave Reisner, David Ward, Elan
        Ruusamäe, Frederic Crozat, Gergely Nagy, Guillermo Vidal,
        Hannes Reinecke, Harald Hoyer, Javier Jardón, Kay Sievers,
        Lennart Poettering, Lucas De Marchi, Léo Gillot-Lamure,
        Marc-Antoine Perennou, Martin Pitt, Matthew Monaco, Maxim
        A. Mikityanskiy, Michael Biebl, Michael Olbrich, Michal
        Schmidt, Nis Martensen, Patrick McCarty, Roberto Sassu, Shawn
        Landden, Sjoerd Simons, Sven Anders, Tollef Fog Heen, Tom
        Gundersen

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


(Log in to post comments)

systemd 183 released

Posted Jun 1, 2012 13:40 UTC (Fri) by nix (subscriber, #2304) [Link]

    * udev: /lib/udev/devices/ are not read anymore; systemd-tmpfiles
      should be used to create dead device nodes as workarounds for broken
      subsystems.

    * udev: RUN+="socket:..."  and udev_monitor_new_from_socket() is
      no longer supported. udev_monitor_new_from_netlink() needs to be
      used to subscribe to events.
And the merciless removal of features which people, and current software, are using, and which were recommended only a few versions ago, continues. This has been happening to udev for some considerable time, and is deeply annoying and potentially-boot-breaking every time it happens. Kay appears to have no grasp of the concept of backward compatibility at all. (Yeah, you can adapt to each change as it happens, which then makes it impossible to *downgrade*. Great.)

(For my own part I'm sticking with udev 175 until it breaks completely, which given the typical lackadaisical approach to backward compatibility in this area might be a few kernel versions away: devtmpfs just fills me with a sense of deep wrongness and layering violations and I don't want to rely on it.)

systemd 183 released

Posted Jun 1, 2012 15:43 UTC (Fri) by ballombe (subscriber, #9523) [Link]

The udev-kernel interdependency is already the major problem when upgrading from a Debian release to another. This makes upgrade much harder than they need to.

systemd 183 released

Posted Jun 9, 2012 21:58 UTC (Sat) by nlucas (subscriber, #33793) [Link]

This is really annoying.

I use /lib/udev/devices to automatically create the /dev/xconsole file on Ubuntu. After the change to upstart that file is no longer created, breaking xconsole.

If I don't have systemd, how can I use systemd-tmpfiles to create this file? Ubuntu will probably "invent" some way of doing this, while others systems will probably "invent" a second way. How is this contributing for the Linux ecosystem?

I also have a minimal udev system without any special init (a script file for sysinit and a second for shutdown). How will future udev work on this system? I'm also delaying using any new udev version while I can.

This situation of making udev "hostage" of systemd should never have been allowed...

systemd 183 released

Posted Jun 10, 2012 0:37 UTC (Sun) by cortana (subscriber, #24596) [Link]

You can run systemd-tmpfiles(8) at some point during bootup and it will do the job.

systemd 183 released

Posted Jun 10, 2012 1:46 UTC (Sun) by nlucas (subscriber, #33793) [Link]

Care to explain how to do it if Ubuntu doesn't have systemd?

systemd 183 released

Posted Jun 10, 2012 13:12 UTC (Sun) by cortana (subscriber, #24596) [Link]

I expect ubuntu will drop their udev source package in favour of a systemd source package that produces a udev binary package, and a systemd-utils binary package including the misc utilities that others may find useful such as systemd-tmpfiles. Alternatively they could patch their udev code to re-instate the feature--it's hardly a particularly complex one. Or they could re-implement it, or adopt Debian's create_static_nodes script. Or adopt Debian's approach of having the rsyslog package create the FIFO (it's a simple change to the init script for the syslog daemon).

systemd 183 released

Posted Jun 10, 2012 18:31 UTC (Sun) by nlucas (subscriber, #33793) [Link]

Why should you expect they include systemd-utils? I'm sure many of those utilities only work with systemd, so why should they package a mostly-broken package?

And if they adopt the current debian way (which by the way could now be considered obsolete because udev already changed how things should be done), then you have different ways of doing things on different distros. So what are the wins of using a new udev?

Anyway, I'm not talking of Ubuntu per si to do this. I'm asking of a way for users to do this in a compatible way.

What assurance can anyone have of any way they choose udev will not change it's mind again, now expecting people to have this things on a xml file on /etc/udev/extra-devices.xml and automatically removing any device not listed there?

I'm not a big fan of the kernel internal unstable API, but I can understand it's good points and accept it as a choice made by them. This, on the other hand, is just gratuitous incompatible changes into the user-space API without any good points I can see (other than breaking because it's "prettier" this way).

This is hardly the way into unifying the plumbing on Linux systems...

systemd 183 released

Posted Jun 10, 2012 18:58 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

"I'm sure many of those utilities only work with systemd, so why should they package a mostly-broken package?"

This is a invalid assumption.

systemd 183 released

Posted Jun 11, 2012 14:08 UTC (Mon) by nlucas (subscriber, #33793) [Link]

That surprises me a lot.
Why call it systemd-utils then? Shouldn't it be just udev-utils? And be part of udev only?

Doesn't make much sense. What user will guess that it needs to install a package with a name of other that doesn't exist on his system to get utilities for a second package?

systemd 183 released

Posted Jun 11, 2012 14:18 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

You are confused. There is no separate upstream release called system-utils. OP's suggestion was to package a bunch of the independent tools under a distribution package by that name. systemd-tmpfiles for instance is only called by that name since it was written as part of the systemd project. It doesn't depend on systemd being the init system. Even if reimplementation is needed by distributions who haven't used systemd, documentation on the interfaces already exist and independent reimplementations have been written by various distributions as well.

http://www.freedesktop.org/wiki/Software/systemd/Interfac...

systemd 183 released

Posted Jun 11, 2012 17:15 UTC (Mon) by nlucas (subscriber, #33793) [Link]

You are right. I was confused. Thanks for the link so I could clear this up.

Either way, a user-space udev API was broken. The solution pointed was to use a systemd API to solve the problem.

It's still a compatibility breakage, and if that solution is to be used across distributions it should be discussed outside systemd, not forced on all distributions. udev is a crucial Linux plumbing infrastructure. systemd isn't (at least not yet) so it can not force global policy and compatibility APIs.

The same applies for DBUS. It can eventually be considered an essential package on desktop Linux, but it's far from it on a global scale. So udev can make a DBUS API available, but never have an hard dependency on DBUS (or any DBUS utilities or API).

For example, there may be reasons for having udev on an Android system, but there are no strong reasons to have DBUS or systemd. The same for other specific-use or embedded Linux systems.

systemd 183 released

Posted Jun 11, 2012 17:38 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

The primary developer of udev is one of the co-maintainers of systemd upstream and hence they are working together on some changes. This isn't forced on anybody anymore than any other upstream choices in development is. Distributions are free to patch it back or reimplement interfaces as they already have and systemd developers go out of their way to document these interfaces and provide a stability promise to make all of this easier.

It is arguable that systemd isn't crucial infrastructure yet but I dont consider it valid to argue that dbus isn't for desktop linux. All major desktop environments and several critical desktop applications depend on it. Note that systemd depends on the dbus protocol and not the daemon. Android certainly doesn't count as evidence for that considering that it is a entirely separate ecosystem that shares pretty much nothing other than the kernel.

systemd 183 released

Posted Jun 11, 2012 17:57 UTC (Mon) by sfeam (subscriber, #2841) [Link]

To the best of my knowledge Xfce does not require dbus.

systemd 183 released

Posted Jun 11, 2012 18:10 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Update your knowledge.

http://docs.xfce.org/xfce/building

systemd 183 released

Posted Jun 11, 2012 18:45 UTC (Mon) by sfeam (subscriber, #2841) [Link]

According to the release notes for Xfce 4.10-pre1, dbus is a "soft requirement" for some of the new functionality. I took them at their word, but I admit to not having tried building without it. In earlier versions it was only listed as being required for thunar.

systemd 183 released

Posted Jun 11, 2012 18:52 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

The thing about "soft requirements" is that unless you are using a source based distros, it is highly likely your distro of choice will pull it in when you install Xfce. dbus is effectively a requirement for Linux desktop.

systemd 183 released

Posted Jun 11, 2012 18:35 UTC (Mon) by nlucas (subscriber, #33793) [Link]

It seems to me we give different weights to different things. For me, any user space API breakage is wrong without *very strong* reasons. And it's worst if that breakage is in a crucial package like udev.

I did say that dbus is an important desktop package, so we don't disagree there (we could disagree on if it should be or is desirable that it is, but that's irrelevant). I don't think it's an essential package, but it's certainly desirable for everything to work as expected from the user point of view. It certainly is possible to use a Linux system, even with X, without it.

My point was that dbus is not an essential package on every system (servers, for example, if you believe Android and the other billions of custom systems are irrelevant), so udev should never depend on it, in the same way that udev should never depend on systemd, because it's another non-essential package.

Note that I'm not saying udev should remove all DBUS interfaces it already implements. I'm just saying it should be possible to use it without dbus.
In the same way, there is no problem on udev implementing systemd hooks, as long as it doesn't force the use of systemd to udev users.

There is nothing strange here. The same can be said on any other non-essential package, like having udev depend on python, or java. But nothing forbids udev for having python or java interfaces on the systems where they are available.

systemd 183 released

Posted Jun 11, 2012 18:48 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

It is possible to continue using udev without systemd or dbus so I am not sure what your point is, really. Having said that, dbus isn't limited to desktop systems anymore since cups and even bind can take advantage of it.

systemd 183 released

Posted Jun 11, 2012 21:20 UTC (Mon) by nlucas (subscriber, #33793) [Link]

My point is the same as the original poster on this thread: gratuitous incompatible changes on a core package is BAD.

I don't agree with you on dbus, but that's irrelevant (just because dbus can be used on a server doesn't mean it's required or essential).

systemd 183 released

Posted Jun 12, 2012 10:31 UTC (Tue) by cortana (subscriber, #24596) [Link]

The breakage is annoying but we could, at least in theory, end up in a situation where all distributions use the same /etc/tmpfiles.d configuration method. IMO that is worth a bit of pain. Particularly when the new method is better documented than the old one: I don't ever remember hearing about /lib/udev/devices until this discussion: for whatever reason Debian doesn't even use it, it has its own /etc/udev/links.conf file that explicitly says in its header that "This file does not exist. Please do not ask the Debian maintainer about it.", etc.

OTOH we could end up in the situation evoked by http://xkcd.com/927/. Maybe it's naive to be so optimistic, but a world where everything in http://www.freedesktop.org/wiki/Software/systemd/Interfac... is adopted by all distributions would be quite pleasant: a world where you could configure all this low-level stuff on any distribution without having to deal with all the pointless differences between them.

http://0pointer.de/blog/projects/the-new-configuration-fi... has more info about the rationale for all of this. Admittedly it's a long shot for the distributions that aren't adopting systemd as their primary init system.

systemd 183 released

Posted Jun 12, 2012 11:00 UTC (Tue) by nlucas (subscriber, #33793) [Link]

Debian is (at least in theory) kernel agnostic, so it can't depend on udev, which is Linux specific.

You may never heard of /lib/udev/devices but that just means you never needed it. It was added when /dev started being a tmpfs filesystem (and now devtmpfs), because devices were no longer preserved across reboots.

At the time was not an API break, because people could still use a static /dev, and so was backward compatible. In the meantime other breakages occurred.

Anyway, the problem here is not this specific feature: it's the fact that udev AGAIN broke an API. The problem is not systemd or any other software, it's the fact people working on the core Linux plumbing are constantly annoying it's users.

This would not be a problem if we had some user-space wrapper abstracting this lower level stuff. But we do not, so please don't regard low level APIs as things that can change any time just because they can. They are as much standard APIs as brk(), sbrk() or malloc(), and there are people using it.

systemd 183 released

Posted Jun 12, 2012 12:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Udev is arguably special in that regard. It's in constant flux because of new hardware or new ways to configure it.

Udev's primary API is /dev filesystem structure - which is stable, btw.

systemd 183 released

Posted Jun 12, 2012 13:06 UTC (Tue) by nlucas (subscriber, #33793) [Link]

The kernel is in the same state of flux and that doesn't mean the user-space API is broken.

/dev is only one of the udev API's. libudev is another, as are the DBUS bindings.
The udev rules are another API (one that is constantly breaking too).

None of them should be considered second order APIs. If they exist they will be used by someone somewhere. If they break, someone will be annoyed. If they are constantly breaking more "someones" will be annoyed.

One thing that seems not everyone grasps is that Linux has probably more usage in customized systems than on desktops. udev was published as the rescue for this low-level plumbing, even on customized systems, because USB happened (needed to load modules on demand, creating/removing devices, etc). This systems could use other things (like mdev), but udev is the only one generic enough for most usages (mdev doesn't cover all modular cases).

Android decided to not use udev, but it will need to reinvent it (if it doesn't start using it) for the generic tablet cases (when tablets, maybe docked, replace laptops).

systemd 183 released

Posted Jun 12, 2012 13:09 UTC (Tue) by nlucas (subscriber, #33793) [Link]

By the way, I don't mind a little API break once in a while. It's good to cleanup accumulated cruft.

The problem is the constant breakage, not one or other "flag day".

systemd 183 released

Posted Jun 13, 2012 16:24 UTC (Wed) by nix (subscriber, #2304) [Link]

Quite. They even moved the daemon around between releases and didn't even have the courtesy to maintain a compatibility symlink (total cost: one line of code in Makefile.am's install rules). I can see no advantage to moving the daemon out of the directory where all other system daemons are located -- it was just done for the hell of it, as far as I can see, but of course it meant everyone had to adjust their boot scripts, and either load them up with compatibility crap in case of downgrades or lose the possibility of downgrading without breaking boot.

(However, they *are* very good at telling you what the compatibility breaks will be, so you *can* adapt to them. But every upgrade feels like skydiving with a possibly-broken parachute, and it shouldn't.)

systemd 183 released

Posted Jun 11, 2012 22:07 UTC (Mon) by nix (subscriber, #2304) [Link]

Either way, a user-space udev API was broken.
This seems to happen every month or so. It's not like this is the first or even the tenth time. Most of the changes add no value that I can see.

I'm frankly sick of it, so I'm sticking with udev 175 until it breaks, and then backporting appropriate kernel changes to keep it working, or forking it with the intent of maximum compatibility with existing installations, whichever is easier.

systemd 183 released

Posted Jun 11, 2012 22:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Uhm.

Udev is a very low-level component. Why are you maintaining your own config instead of using distro-provided one (maybe with small customizations)?

systemd 183 released

Posted Jun 12, 2012 7:33 UTC (Tue) by nix (subscriber, #2304) [Link]

Because I am a UI stability freak. I have extreme distaste for people breaking my working environment, so every physical system I own is currently LFS simply so that user-facing components on whose UI I rely can avoid being jumped to versions that change the user interface in major ways. Not udev, as such (that's just very annoying: I have to run it but I don't like to be bothered by it), but things like the desktop environment, for instance. Now maybe I should just be using xfce, but it so happens I'm a KDE 3.x + fvwm user. These days, some people package Trinity, but there was a long time when I was using KDE 3.5.10 and no vaguely up-to-date distro packaged it: there are other major components that I am intentionally far behind the curve on too. At the same time I want or need to use bleeding-edge trunk versions of some things (kernels, toolchains, QEMU, Emacs, Chromium), a lot of which have substantial local patches applied.

There are few distros optimized for stick-in-the-muds who also need to use and patch bleeding edge low-level software, and I can understand that. Nobody else is likely to want to use the same combinations of bleeding-edge stuff as I am, and handling all the possible combinations is a combinatorial explosion. Most people in this position use a distro, locally compile lots of stuff, and try to cope with the much-too-frequent disruptive UI changes. I'm not willing to do that. Sometimes this means I whine about people who assume that everyone uses a distro that someone else maintains (and that downgrades never happen) and that they can break low-level components' compatibility frequently without anyone at all caring. People like me do still exist. We may be a small constituency of control-freakish eccentrics but we are not nonexistent. :)

(As a side note, the reasonably high degree of low-level knowledge that doing this sort of thing requires *did* actually get me a pretty damn good job. So it wasn't a complete waste of time after all!)

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds