Why systemd should have ignored SysV init script LSB dependencies

March 26, 2015

In his (first) comment on my recent entry on program behavior and bugs, Ben Cotton asked:

Is it better [for systemd] to ignore the additional [LSB dependency] information for SysV init scripts even if that means scripts that have complete information can't take advantage of it?

My answer is that yes, systemd should have ignored the LSB dependency information for System V init scripts. By doing so it would have had (or maintained) the full System V init compatibility that it doesn't currently have.

Systemd has System V init compatibility at all because it is and was absolutely necessary for systemd to be adopted. Systemd very much wants you to do everything with native systemd unit files, but the systemd authors understood that if systemd only supported its own files, there would be a massive problem; any distribution and any person that wanted to switch to systemd would have to rewrite every SysV init script they had all at once. To take over from System V init at all, it was necessary for systemd to give people a gradual transition instead of a massive flag day exercise. However, the important thing is that this was always intended as a transition; the long run goal of systemd is to see all System V init scripts replaced by units files. This is the expected path for distributions and systems that move to systemd (and has generally come to pass).

It was entirely foreseeable that some System V init scripts would have inaccurate LSB dependency information, especially in distributions that have previously made no use of it. Supporting LSB dependencies in existing SysV init scripts is not particularly important to systemd's long term goals because all of those scripts are supposed to turn into units files (with real and always-used dependency information). In the short term, this support allows systemd to boot a system that uses a lot of correctly written LSB init scripts somewhat faster than it would otherwise have, at the cost of adding a certain amount of extra code to systemd (to parse the LSB comments et al) and foreseeably causing a certain amount of existing init scripts (and services) with inaccurate LSB comments to malfunction in various ways.

(Worse, the init scripts that are likely to stick around the longest are exactly the least well maintained, least attended, most crufty, and least likely to be correct init scripts. Well maintained packages will migrate to native systemd units relatively rapidly; it's the neglected ones or third-party ones that won't get updated.)

So, in short: by using LSB dependencies in SysV init script comments, systemd got no long term benefit and slightly faster booting in the short term on some systems, at the cost of extra code and breaking some systems. It's my view that this was (and is) a bad tradeoff. Had systemd ignored LSB dependencies, it would have less code and fewer broken setups at what I strongly believe is a small or trivial cost.


Comments on this page:

By Lennart at 2015-03-26 03:38:40:

It's not that simple. It's not just a question whether to ignore or not to ignore the LSB headers. It's a question of being able to order the SysV/LSB scripts against the native unit files. With the LSB header info we can do that to a certain level: if an LSB script says it wants to be started after "mysql", and "mysql.service" is already a native systemd unit file, then we can actually make sense of this, and add an "After=" dependency on the right unit file. If however you'd ignore the LSB header dependencies entirely, and would only take the sysv Sxx symlinks into account then you could use this to order sysv scripts against each other, but certainly not order relatively to native unit files, because the native unit files have no Sxx symlink numbers...

BTW, we try to keep track of the incompatibilites between systemd and sysv/LSB here:

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

Lennart

So, in short: by using LSB dependencies in SysV init script comments, systemd got no long term benefit and slightly faster booting in the short term on some systems, at the cost of extra code and breaking some systems. It's my view that this was (and is) a bad tradeoff. Had systemd ignored LSB dependencies, it would have less code and fewer broken setups at what I strongly believe is a small or trivial cost.

That's a reasonable position that I happen to disagree with. Perhaps my view is colored by the fact that I mostly deal with init on my personal Fedora systems (where most init files were migrated by the distribution) or via abstracted, single-purpose systems managed by Chef. It's easy for me to say "this isn't much of a problem" because it hasn't been much of one for me.

I'd be interested in a study that looked at a large sample of init scripts across distributions to see how prevalent such breakage really is.

By cks at 2015-03-26 14:33:54:

Lennart makes a good point, so let me revise my view of what systemd should be doing to a more sophisticated one:

  • systemd should never reorder System V init scripts relative to each other, regardless of what LSB dependency information says. If you have a script at S20 and one at S40, they're guaranteed to be started in that order.

  • systemd should insert what are essentially synthetic SysV init scripts at appropriate priority levels that correspond to core historical SysV init scripts. For example, whether or not a SysV init script declares an explicit dependency on $network, systemd ought to behave as if there was a real S10network init script and so order real SysV init scripts relative to it. These native units don't block each other, just actual SysV init scripts.

    (Some or all of this could be done through explicit use of SysVStartPriority, if one changes its definition to apply to scripts with LSB headers as well and added it to various unit files.)

If SysV init scripts declared explicit LSB dependencies, systemd should then take them into account too. A SysV script that said it required 'mysql' would get an "After=" dependency as well, and so potentially have its startup (and the startup of everything behind it) delayed until mysql.service had been started.

(The native systemd units that have this SysV ordering applied to them should be at least the LSB $ facility names. Yes, I know, this includes $network and systemd people don't like the idea of having a defined 'network' startup point. Tough; this is for compatibility and compatibility is always messy. In many server environments such a startup point really does exist because the networking is static.)

By liam at unc edu at 2015-03-27 09:37:17:

I think this is the worst failing of systemd - our way or the highway, if our way breaks what you've been doing lo these last 15 years well screw you, get with the party.

Now, that may not be their intended stand, but it's the actual stand that shows up in their actions and interactions.

By James (trs80) at 2015-03-27 21:41:39:

I have a little bit of sympathy to your revised position, but not much, since Debian has been using those dependencies for over four years.

Admittedly Debian sysvinit is not "Real System V init", and I can agree that both will respect the ordering on the filesystem during actual boot, whether it's manual or insserv-determined, and as such systemd should too.

Written on 26 March 2015.
« A significant amount of programming is done by superstition
Looking more deeply into some SMTP authentication probes »

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

Last modified: Thu Mar 26 00:21:46 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.