bash code in rc.local not executing after bootup

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.

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)

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.

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.

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?

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

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

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

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.

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.

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.