5

I am creating a startup script (called from rc.local) in Debian Squeeze. The startup script checks for a variable value from a file, decrements the variable and writes it back to the file, then if the variable was greater than 0 then it executes a test and reboots the system. If the variable is 0 or less than 0, then it doesn't reboot the system. My question is as follows: Suppose I realize after a couple of tests that there is a bug in the test. Is there any way to break the execute_test->reboot->repeat loop that I have set up. Putting a "sleep 1000" in the test or doing a ps aux|grep might work, but I am not sure if I shall have access to them before the rc.local scripts have run. What if I run the script in the background instead of the foreground? Would I have access to bash login shell etc. while the test is running in the background in that case?

 COUNT=`cat $testFile|wc -l`
 if [ $COUNT -gt 0 ];then
                ARGS=`head -1 $testFile`
                cd /testCode
                /testCode/startTest.sh $ARGS
                sed -i '1d' $testFile
                echo "rebooting"
                /sbin/reboot &
                exit 0
            fi

I know I have given very few details, since I am not sure what information would be required. I will update the question as required.

UPDATE: I ran the test. I get the login prompt before the test finishes. I had though that I would get the login prompt only after rc.local is done executing. Could someone throw light on that?

Gilles 'SO- stop being evil'
  • 829,060
FirstName LastName
  • 555

2 Answers2

2

just replace /sbin/reboot by a conditional reboot

[ -r /noreboot ] || /sbin/reboot

then if you do not want to reboot, simply touch /noreboot and you are good, no matter what the script is doing at the time, as long as it has not yet rebooted.

you also can just boot the system with a livecd and comment out the reboot line in rc.local when you found a bug.

johnshen64
  • 516
  • 2
  • 4
2

You don't get a login prompt until after /etc/rc.local has finished executing.

If you want to allow logins while the test is executing, put the text in a crontab with @reboot for the date fields, or run the tests in the background in /etc/rc.local. Beware that it's likely to be surprising if the machine reboots suddenly a few minutes after someone's logged in. You'd better have an /etc/motd that notifies users that this is happening.

Gilles 'SO- stop being evil'
  • 829,060
  • I ran the test. I get the login prompt before the test finishes. I had though that I would get the login prompt only after rc.local is done executing. Why is that happening? The test can be seen running in ps aux. I had called the test as a foreground process, but I see that the status in ps aux is without a + (indicating background). This doesn't hamper my test, but why is this happening? – FirstName LastName Aug 27 '13 at 17:31
  • Even earlier, when I used to run the test manually, it would always run as a foreground process till completion. – FirstName LastName Aug 27 '13 at 17:32
  • @AlastorMoody You don't get a text mode prompt until after /etc/rc.local, but I see that the way it's set up on Debian, graphical logins become possible before or after rc.local depending on whether the script to start the display manager comes before or after rc.local in alphabetical order. Odd. – Gilles 'SO- stop being evil' Aug 27 '13 at 18:40
  • Where did you find that information? If you could direct me to the source, I could read them up and save you some bother. Also it is a debian squeeze machine without a GUI. I don't know if that is relevant. I am getting a text mode prompt like this: 
    `MachineName login:'
    – FirstName LastName Aug 27 '13 at 18:46
  • 1
    @AlastorMoody Work through the init scripts: /etc/inittab, /etc/rc?.d. Text mode prompts come from the entries in /etc/inittab while GUI and SSH logins come from services started via /etc/rc2.d/* (e.g. /etc/rc2.d/S??sshd, /etc/rc2.d/S???dm). (Note: I'm simplifying a little.) This depends on the init system used: what I wrote here is for SysVinit (the default on Debian) and works differently with Upstart or Systemd. – Gilles 'SO- stop being evil' Aug 27 '13 at 19:34
  • How does the crontab file allow someone to log in? – Melab Aug 15 '17 at 17:40
  • @Melab I don't understand the question. Where did you see a claim that a crontab file allows someone to log in? – Gilles 'SO- stop being evil' Aug 15 '17 at 17:41
  • You said that if someone wants to allow logins while the test is executing, then they must use a crontab. Part of that implies the init process is still in the startup stages. – Melab Aug 15 '17 at 17:43
  • @Melab No, that's not what I wrote, and anyway it wouldn't imply that a crontab allows someone to log in. If you want to allow logins while the test is executing, you let the system start up normally, and at the end of the startup procedure, logins are allowed. Cron has nothing to do with that. Using a cron job is a solution (not the only possible solution, just a convenient one) to run the test without preventing the normal way that allows users to log in. The crontab runs the test. It doesn't create a way to log in, the point of using it is that it doesn't interfere with the normal way. – Gilles 'SO- stop being evil' Aug 15 '17 at 17:51
  • So the init process won't hang while the test is being performed? – Melab Aug 15 '17 at 18:00