Well, I have found the bug. The way it is written, invoke-rc.d would
never get exit status 1 from runlevel. This bug has been in there since
invoke-rc.d was deployed, and I won't pretend I recall why I screwed
that up more than 8 years ago.
Now, fixing it is not difficult. However, it is a codepath that was
NEVER reached before, so a lot of stuff out there might object to
invoke-rc.d exiting with status 102 in every chroot that /sbin/runlevel
doesn't like.
Maybe it would make more sense to proceed with an unknow runlevel,
instead. Invoke-rc.d can deal with it, it will just ignore any symlinks
(it won't even test them), call policy-rc.d without a runlevel (which is
supported by the interface) if one exists, and behave as it would for a
initscript missing the symlinks.
Any ideas of what we should do? The attached patch implements the
above, for reference.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Index: invoke-rc.d
===================================================================
--- invoke-rc.d (revision 1784)
+++ invoke-rc.d (working copy)
@@ -271,13 +271,12 @@
fi
## Queries sysvinit for the current runlevel
-RL=`${RUNLEVEL} | sed 's/.*\ //'`
-if test ! $? ; then
+RL=$(${RUNLEVEL})
+if test $? -ne 0 ; then
printerror "could not determine current runlevel"
- if test x${RETRY} = x ; then
- exit 102
- fi
RL=
+else
+ RL=${RL##* }
fi
## Running ${RUNLEVEL} to get current runlevel do not work in the boot
