bash code in rc.local not executing after bootup

Question

Does anyone know why a system would not execute the script code within rc.local on bootup? I have a post configuration bash script that I want to run after the initial install of VMware ESX (Red Hat), and for some reason it doesn't seem to execute. I have the setup to log its start of execution and even its progress so that I can see how far it gets in case it fails at some point, but even when I look at that log, I am finding that didn't even started the execution of the script code. I already checked to see that script has execution permissions (755), what else should I be looking at?

Here is the first few lines of my code:

#!/bin/sh
echo >> /tmp/configLog ""
echo >> /tmp/configLog "Entering maintenance mode"

Solution 1

So, does /tmp/configLog exist? If so, your script is firing, and it's just dying somewhere.

Start with the basics:

1. Put a simple, one-liner in /etc/rc.local, like this.

   touch /tmp/itworked

   Did that work? After rebooting, does /tmp/itworked exist? If so, then rc.local is being executed.
2. Another common gotcha is that if your script is a daemon it either needs to handle forking to the background, or it needs to be backgrounded in rc.local. If your script is /bin/myscript, then rc.local should have:

   /bin/myscript &

   in it. Does it take a long time to run? There may be a timeout somewhere in the init scripts to prevent users from halting the boot process - backgrounding the process will get you around that if it exists.
3. If the 'touch' works, and you're backgrounding, it has to be in your script somewhere. What does it do when you run

   /bin/sh /etc/rc.local

   from the command line?
4. Like Jason said, check dmesg, as well as /var/log/messages for any clues.
5. When the script is ran from rc.local, it will not have the full set of environment variables that your root user has when logged in - e.g. $PATH may be different. Don't rely on $PATH. You can also test your script by scheduling an 'at' job which will come close to simulating the environment.

Solution 2

Are you sure your system supports rc.local? If it isn't documented, you will need to follow all of the init scripts. You start at /etc/inittab. (You may find that from there you go to /etc/rc.d/rc)

On some systems, /etc/rc.d/rc.local is supported via a symlink /etc/rc.d/rcX.d/S99local. (where X is the appropriate runlevel).

If you're using RedHat, there's no real reason to not create your own init script, add it to /etc/rc.d/init.d, chkconfig --add the script, and chkconfig on the script. This will make the correct symlinks into the /etc/rc.d/rcX.d directories, and makes init scripts easy to deploy or disable.

Making use of the obsolete rc.local is fine for a quick hack if your system does support it, but it's not really appropriate for something important or permanent.

Solution 3

Not sure if processing of init scripts on linux is sequential or parallel, but Solaris systems launch the scripts sequentially. If an earlier init script hasn't yet finished (I see this sometimes due to sendmail/DNS dependency) the later ones don't get launched as quickly as you'd assume.

Use ps to see if an earlier init script is still running.

Solution 4

It's not something simple like a typo is it? Should this:

#!/bin/hash

Really be:

#!/bin/bash

?

(Just like CK said in comment, now that I look)

View more solutions

Comments

[Joel]

I'll try that, but does bash compile the script code before executing or does it just run start running? Reason why I ask is that I got the impression that it just starts running and so if I ave a syntax error on line 50, the script would run 1-49, and then stop because of this error. Or does it not run at all when there is a error present anywhere in the script file? Please see my update whoch shows the first few lines of the script.

[Joel]

in regards to the echoing, either way works. I do it this way just so the echoing of many things looks clear when reviewing the code.

[Dave Klotz]

Scripts execute line by line, it would break at line 50 once it got there if there was an error on line 50.

[krx]

how bout the first line? generally i think rc.local execution needs to be enabled for your distro.

[pjz]

stop on error is a (default on) option. look up what 'set -e' does.

[Scott]

Just thought I'd revisit the typo on the first line of the script. If it's a copy/paste then it should be /bin/bash, rather than /bin/hash (unless you really want to use the Haskell Shell).

[Admin]

I find running a script with bash -x helps me see what bash sees when it parses a script.

[Chaim Geretz]

Many implementations of init (including Sysvinit used in many Linux distributions) start processes in a pre-determined order, and only start a process once the previous process finishes its initialization. en.wikipedia.org/wiki/Initng#Purpose