I tested a bit, to see if there is a way to detect the runlevel when
the scripts in /etc/rcS.d/ is being executed, and the closest thing I
could find is the init argument as reported by ps.
It is 'init boot' while /etc/rcS.d/ is executed, and 'init [2]' etc
when a real runlevel is entered. The boot runlevel isn't a real
runlevel, and that is the source of this issue.
Can you test this patch to see if it solve your problem?
index: debian/sysv-rc/sbin/invoke-rc.d
===================================================================
--- debian/sysv-rc/sbin/invoke-rc.d (revision 1087)
+++ debian/sysv-rc/sbin/invoke-rc.d (working copy)
@@ -280,6 +280,15 @@
RL=
fi
+## Running ${RUNLEVEL} to get current runlevel do not work in the boot
+## runlevel (scrints in /etc/rcS.d/), as /var/run/utmp contain
+## runlevel 0 or 6 at that point.
+if test x${RL} = x0 || test x${RL} = x6 ; then
+ if ps -fp 1 | grep -q 'init boot' ; then
+ RL=S
+ fi
+fi
+
## Handles shutdown sequences VERY safely
## i.e.: forget about policy, and do all we can to run the script.
## BTW, why the heck are we being run in a shutdown runlevel?!
It might be an idea to replace 1 with the content of
/proc/sys/kernel/cad_pid, to make sure the correct init is consulted
even if it isn't pid 1. Also, I am unsure how this will work in a
chroot. I see from #361717 that invoke-rc.d do not work perfectly in
a chroot either.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
