Chris's Wiki :: blog/linux/SystemdLSBDependenciesMistake Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/SystemdLSBDependenciesMistake?atomcommentsDWiki2015-03-28T01:41:39ZRecent comments in Chris's Wiki :: blog/linux/SystemdLSBDependenciesMistake.By James on /blog/linux/SystemdLSBDependenciesMistaketag:CSpace:blog/linux/SystemdLSBDependenciesMistake:b333600fe1569b449e7cf88ed2838f33a32c24dbJames<div class="wikitext"><p>I have a little bit of sympathy to your revised position, but not much, since Debian has been using those dependencies <a href="https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot">for over four years</a>.</p>
<p>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.</p>
</div>2015-03-28T01:41:39ZBy liam at unc edu on /blog/linux/SystemdLSBDependenciesMistaketag:CSpace:blog/linux/SystemdLSBDependenciesMistake:f0e8ceffe88c86ac1295af656a57a5aa2ac8df9cliam at unc edu<div class="wikitext"><p>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.</p>
<p>Now, that may not be their intended stand, but it's the actual stand that shows up in their actions and interactions.</p>
</div>2015-03-27T13:37:17ZBy Chris Siebenmann on /blog/linux/SystemdLSBDependenciesMistaketag:CSpace:blog/linux/SystemdLSBDependenciesMistake:8940ea1fc47194058b686b98410319f917521c47Chris Siebenmann<div class="wikitext"><p>Lennart makes a good point, so let me revise my view of what systemd
should be doing to a more sophisticated one:</p>
<ul><li>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.<p>
</li>
<li>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 <code>$network</code>, systemd ought to behave as if
there was a real <code>S10network</code> 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.<p>
(Some or all of this could be done through explicit use of
<code>SysVStartPriority</code>, if one changes its definition to apply to scripts
with LSB headers as well and added it to various unit files.)</li>
</ul>
<p>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.</p>
<p>(The native systemd units that have this SysV ordering applied to
them should be at least the LSB <code>$</code> facility names. Yes, I know, this
includes <code>$network</code> 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.)</p>
</div>2015-03-26T18:33:54ZBy Ben Cotton on /blog/linux/SystemdLSBDependenciesMistaketag:CSpace:blog/linux/SystemdLSBDependenciesMistake:862b37535cde76277379ef80b161f9c1b16d77f9Ben Cottonhttp://www.funnelfiasco.com<div class="wikitext"><blockquote><p>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.</p>
</blockquote>
<p>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.</p>
<p>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.</p>
</div>2015-03-26T12:32:14ZBy Lennart on /blog/linux/SystemdLSBDependenciesMistaketag:CSpace:blog/linux/SystemdLSBDependenciesMistake:21ba74c494017fdd807ceb6f64f4aabfaef66814Lennart<div class="wikitext"><p>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...</p>
<p>BTW, we try to keep track of the incompatibilites between systemd and sysv/LSB here:</p>
<p><a href="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/">http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/</a></p>
<p>Lennart</p>
</div>2015-03-26T07:38:40Z