The short question: Is it acceptable to boot a server into runlevel 1, and then invoke "init 2" from an /etc/rc1.d script to interrupt the execution of any further scripts in that runlevel and continue in RL2?
The long story: We have a setup with multiple servers (running Wheezy). When booting, the servers check whether updates are available on a master server. If available, they are pulled in through a dist-upgrade. This check/update needs to happen before any of the normal services are started, to avoid the need of taking down everything and then starting it back up after the update. The most sane thing to do would be to perform this check/update as the very first init script in runlevel 2. This however seems impossible to guarantee, aside from the unmaintainable practice of adding every possible service to the Required-Start field of this script. There is a way to make a script run last (Required-Start: $all), but as you may have guessed, "X-Start-Before: $all" does not work. The next most sane thing to do would be to run the script at the end of runlevel S. When we do this however, the dist-upgrade will often hang indefinitely after the unpacking stage. Any attempt to perform the upgrade while we're still in level S, results in the same hang. Therefore to both avoid this hang and guarantee that the update is performed before any runlevel 2 service, we boot the servers into runlevel 1 and check the update there. The init script is configured as "X-Start-Before: killprocs", because we do not want anything to be killed at boot. /etc/rc1.d therefore looks like this: S01bootlogs S01motd S01magic-update-script S02killprocs S03single To allow runlevel 1 to be used normally, the script does nothing if this is not the first runlevel after boot. Otherwise it does its thing, and when done invokes "init 2" to replace the entire shell and therefore (in theory) prevent S02killprocs and S03single from being executed. This works fine in most cases. On one particular server however, we noticed that killprocs was sometimes (in about 20% of all boots) still being executed even though the 'runlevel' command already reports the current level to be 2. We managed to work around this by adding an extra check to the killprocs script that skips it if the runlevel is not 1. However, we realize that what we're doing might not be perfectly sane and wonder whether it might have other risks. We could avoid this 'init-inside-an-initscript' hack if someone had a foolproof way of guaranteeing that the init script is always executed as the very first in runlevel 2. -- Alexander Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKr4yMxo8VQiy7w8JRZf3Uh-snEygCxxsJsv8o=yq-ygi_w...@mail.gmail.com
