2

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"
Improve this question

10 Answers 10

Reset to default
4

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.
Improve this answer
1

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)

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
1
  • 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, 2011 at 16:38
0

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?

Improve this answer
4
  • 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, 2009 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.
    – sclarson
    May 18, 2009 at 19:24
  • stop on error is a (default on) option. look up what 'set -e' does.
    – pjz
    May 20, 2009 at 5:40
  • I find running a script with bash -x helps me see what bash sees when it parses a script.
    – user1804
    Aug 3, 2009 at 13:09
0

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

Improve this answer
0

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

#!/bin/bash
echo "" >> /tmp/configLog
echo "Entering maintenance mode" >> /tmp/configLog
Improve this answer
3
  • 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, 2009 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, 2009 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, 2009 at 13:53
0

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .