Linux – bash code in rc.local not executing after bootup

bashlinuxunixvirtualizationvmware-esx

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"

Best Answer

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.
Related Topic