Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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"
share|improve this question

10 Answers 10

Perhaps there is a syntax error in the rc.local script. If you try to manually run it from the command line after the system has booted, does it execute correctly?

share|improve this answer
    
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. –  mrTomahawk May 18 '09 at 18:20
    
Scripts execute line by line, it would break at line 50 once it got there if there was an error on line 50. –  sparks May 18 '09 at 19:24
    
stop on error is a (default on) option. look up what 'set -e' does. –  pjz May 20 '09 at 5:40
    
I find running a script with bash -x helps me see what bash sees when it parses a script. –  Andrew H Aug 3 '09 at 13:09

Have you checked the permissions on the directory which contains the rc.local file?

share|improve this answer

Shouldn't your code look more like this? 3 changes here:

#!/bin/bash
echo "" >> /tmp/configLog
echo "Entering maintenance mode" >> /tmp/configLog
share|improve this answer
    
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. –  mrTomahawk May 18 '09 at 18:47
    
how bout the first line? generally i think rc.local execution needs to be enabled for your distro. –  Ian Kelling May 18 '09 at 22:33
1  
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). –  CK. May 20 '09 at 13:53

rc.local was the BSD way of running startup scripts. Although many Linux versions do support having a file called "rc.local" which is run at startup, as I recall these required a bunch of symlinks and other glue to work, as Linux followed the Solaris way of handling startup scripts.

share|improve this answer

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)

share|improve this answer

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.

share|improve this answer

SELinux.

Try getenforce to see if selinux is switched on. It will return 1 or enforcing if it is turned on. Then if it is check dmesg to see if there is an selinux related error that looks like it might be to do with your script.

share|improve this answer

If that first line really does say #!/bin/hash then you will get an error similar to this:

-bash: ./test.sh: /bin/hash: bad interpreter: No such file or directory

when it runs.

You might also want to check that the script has execute permissions.

share|improve this 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.
share|improve this answer

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.

share|improve this answer
    
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 –  Chaim Geretz Jan 3 '11 at 16:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.