The meaning of $all in init.d scripts dependencies (Was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))
[Tollef Fog Heen]
> I'm pointing out why $all doesn't do what you want. «$all» means «after
> everything else has started» and if you have two of those, you have a
> loop. Loops are bugs.
That is a common misunderstanding of what $all means, and probably the
reason why insserv, systemd and openrc handle it differently.
$all was introduced by SuSe in the insserv package, which Debian also
uses to order init.d scripts, and for me that mean insserv is the one
defining what $all mean. The $all facility is not defined in the LSB
3.1.0. In insserv, $all means after all scripts not depending on $all.
This is how it has been used in the two only distributions where the
facility has been in use (Debian and SuSe - are there others?). I thus
suspect most or all init.d scripts in Debian today are based on how
insserv uses $all to order init.d scripts, given that this has been the
reference implementation when dependencies were introduced in init.d
scripts.
A better definition of $all, which to me make more sense than the
current definition in insserv, and which I suspect also would be less
confusing, could be "all scripts not depending directly or indirectly on
$all". This would allow scripts depending on $all to also depend on
each other, and ensure correct ordering also in this case.
According to Tollef, systemd simply ignore $all, inserting scripts with
that dependency as if $all were not present.
And according to Thomas, OpenRC assume scripts depending on $all also
depend on other scripts depending on $all, conclude there is a loop and
try to break the loop at some random point in the perceived loop.
If I understand correctly, Upstart leave it to insserv to order init.d
scripts.
Here are some examples how this will lead to incorrect ordering. Given
scripts A, B and C, where B depend on $all and C depend on $all, both
the correct order would be (A, B, C) and (A, C, B) - both are correct, B
and C can be started in parallel. systemd can end up with the ordering
(B, A, C), (C, B, A), (B, C, A) and (C, A, B) in addition to the correct
ones, because it ignore $all and there are no other dependencies to take
into account. OpenRC see a dependency loop B - C - B and will break it
at a random point, ending by chance up with on of the correct orderings.
Luckily there are not too many scripts with $all listed as its
dependency. But those that use it, really need to run after most of the
scripts in the boot sequence, without being able to list them all.
rc.local is one example, which by definition should be among the last
scripts to run.
--
Happy hacking
Petter Reinholdtsen
Reply to: