Systemd is not fully backwards compatible with System V init scripts

March 23, 2015

One of systemd's selling points is that it's backwards compatible with your existing System V init scripts, so that you can do a gradual transition instead of having to immediately convert all of your existing SysV init scripts to systemd .service files. For the most part this works as advertised and much of the time it works. However, there are areas where systemd has chosen to be deliberately incompatible with SysV init scripts.

If you look at some System V init scripts, you will find comment blocks at the start that look something like this:

# Provides:        something
# Required-Start:  $syslog otherthing
# Required-Stop:   $syslog

These are a LSB standard for declaring various things about your init scripts, including start and stop dependencies; you can read about them here or here, no doubt among other places.

Real System V init ignores all of these because all it does is run init scripts in strictly sequential ordering based on their numbering (and names, if you have two scripts at the same numerical ordering). By contrast, systemd explicitly uses this declared dependency information to run some SysV init scripts in parallel instead of in sequential order. If your init script has this LSB comment block and declares dependencies at all, at least some versions of systemd will start it immediately once those dependencies are met even if it has not yet come up in numerical order.

(CentOS 7 has such a version of systemd, which it labels as 'systemd 208' (undoubtedly plus patches).)

Based on one of my sysadmin aphorisms, you can probably guess what happened next: some System V init scripts have this LSB comment block but declare incomplete dependencies. On a real System V init script this does nothing and thus is easily missed; in fact these scripts may have worked perfectly for a decade or more. On a systemd system such as CentOS 7, systemd will start these init scripts out of order and they will start failing, even if what they depend on is other System V init scripts instead of things now provided directly by systemd .service files.

This is a deliberate and annoying choice on systemd's part, and I maintain that it is the wrong choice. Yes, sure, in an ideal world the LSB dependencies would be completely correct and could be used to parallelize System V init scripts. But this is not an ideal world, it is the real world, and given that there's been something like a decade of the LSB dependencies being essentially irrelvant it was completely guaranteed that there would be init scripts out there that mis-declared things and thus that would malfunction under systemd's dependency based reordering.

(I'd say that the systemd people should have known better, but I rather suspect that they considered the issue and decided that it was perfectly okay with them if such 'incorrect' scripts broke. 'We don't support that' is a time-honored systemd tradition, per say separate /var filesystems.)

Comments on this page:

By dozzie at 2015-03-23 03:47:42:

And there goes technical superiority of systemd's idea on initscripts over upstart's.

Forcing somebody (maintainer) to declare all the dependencies was always going to break init system exactly in this manner. That's why upstart and Gentoo's initscripts were broken by their very design. Seems that systemd is broken in the same way.

By Ben Hutchings at 2015-03-23 11:48:12:

Debian has been using the dependency information since 2009 ( and SUSE was doing so for several years before that.

There's been plenty of time to fix the LSB dependency headers.

I'd argue that "But I was depending on that bug!" is generally a poor justification for nit fixing a bug.

The fact that SysV init runs scripts serially is not a bug.

If you introduce a new interface (dependency graph instead of numerical ordering) but make it irrelevant to the operation of the system, then missing dependency information is not a bug.

If you then change the interface contract to say that order and concurrency shall be based on the dependency graph, without even the option for a transitory period in which people can audit their existing code for compliance to this changed interface contract (that you just changed (did I point this out often enough?)), then the blame is squarely on you.

Ought the scripts be fixed in the long run? If the new interface contract is for the long term, sure. Does that justify breaking everyone’s systems now? Absolutely not.

This is not responsible change management. It is just “screw you guys, I can’t be bothered to be held to anything remotely like engineering standards, too much work”.

By pdkl95 at 2015-03-28 03:33:10:

Yes, sure, in an ideal world the LSB dependencies would be completely correct

Yet another example of systemd's indomitable belief in the just-world fallacy. The spec said it was foo, so there is never any need to check that what was actually implemented might actually be foo, bar and sometimes baz.

Just like the far-too-common political belief that "banning ${activity} with laws" should always result in "fewer people do ${activity}", this assumption of just-world hypothesis seems to point to some sort of is-out perception problem.

Unless, of course, this kind of breakage is simply malicious. :/

Written on 23 March 2015.
« I now feel that Red Hat Enterprise 6 is okay (although not great)
What is and isn't a bug in software »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Mar 23 01:04:53 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.