rc.local script does not run on bootup

[rignes]

Description: Ubuntu 8.04
Release: 8.04

The contents of /etc/rc.local do not run on bootup. However, they run fine when you run sudo /etc/inid/rc.local start

[Jason Thibeault (jthibeault-gmail)]

I can confirm that rc.local is not running for me either. I'm using an HP Compaq 6510b, which apparently has problems with suspending under Ubuntu 8.04 Hardy. The suggested fix for this is to add "echo 1 > /proc/acpi/video/C098/DOS" to /etc/rc.local, which allows the laptop to suspend without hard-locking. However, on bootup, "cat /proc/acpi/video/C098/DOS" returns "DOS Setting: <4>". If I run "/etc/init.d/rc.local start", then "cat /proc/acpi/video/C098/DOS" will return "DOS Setting: <1>" afterward, so I know for certain that running rc.local manually does work.

[Jerzy Mansarliński (jmansar)]

Have you checked if rc.local script is in proper runlevel?

sudo update-rc.d rc.local defaults

[Jason Thibeault (jthibeault-gmail)]

I may not be the bug initiator, but I'm willing to continue troubleshooting.

A symlink to rc.local exists as S99rc.local in runlevels 2, 3, 4, and 5 (/etc/rc#.d/). Ran the defaults command anyway, just to see what would happen:

jthibeault@kent-itmgrlaptop:~$ sudo update-rc.d rc.local defaults
[sudo] password for jthibeault:
 System startup links for /etc/init.d/rc.local already exist.

As for its permissions:

jthibeault@kent-itmgrlaptop:~$ ls -la /etc/rc*.d/S99rc.local
lrwxrwxrwx 1 root root 18 2007-10-24 15:22 /etc/rc2.d/S99rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root 18 2007-10-24 15:22 /etc/rc3.d/S99rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root 18 2007-10-24 15:22 /etc/rc4.d/S99rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root 18 2007-10-24 15:22 /etc/rc5.d/S99rc.local -> ../init.d/rc.local
jthibeault@kent-itmgrlaptop:~$ ls -la /etc/rc.local
-rwxr-xr-x 1 root root 371 2008-05-04 19:42 /etc/rc.local

[Jerzy Mansarliński (jmansar)]

I assume that the rest of the startup scripts work fine.
Could you please add a new script /etc/init.d/test.

#! /bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin
[ -f /etc/default/rcS ] && . /etc/default/rcS
. /lib/lsb/init-functions

do_start() {
  log_begin_msg "Running test script"
  echo "OK" >> /var/log/test
  log_end_msg $?
}

case "$1" in
    start)
 do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

###########################

sudo chmod +x /etc/init.d/test
sudo update-rc.d test defaults

Then reboot and see if it works.

[Jason Thibeault (jthibeault-gmail)]

All the other scripts were running fine to my knowledge, as the system was booting up just fine and I wasn't noticing any odd behaviour that would lead me to believe any of them weren't running as usual. However, I'm completely at a loss as to why, but rc.local seems to be running now. The test script did run properly, and output "OK" to /var/log/test, and also now "cat /proc/acpi/video/C098/DOS" produces "DOS setting: <1>".

I'd like to say that perhaps rc.local was indeed running previously, but it was running before /proc was created, or some such goofy thing, but I can't prove it. I also can't see why creating the test script and installing it in defaults might fix rc.local -- it doesn't make any sense. Sorry I can't be of any further help at the moment. I plan on building another box soon though, so I'll install Hardy and put a test line in rc.local, and if it has problems running it, I'll resume troubleshooting with you.

For what it's worth, I suspect there may be problems with rc.local outside of what I'd experienced -- a quick Google search for "hardy rc.local" turns up this URL: http://www.linuxquestions.org/questions/ubuntu-63/rc.local-doesnt-run-in-hardy-639619/ However, the problem may be with another script not firing, and thus the bootup never really "completing", even though the X server starts.

[Jerzy Mansarliński (jmansar)]

It's good to hear that your system is working properly now. I think you are probably right that rc.local was running previously, but it can't be verified now. Anyway, thank you for your involvement.

I am setting bug status to incomplete.

[rignes (rignes-pobox)]

I'm not sure if this is the proper way to reply to this as I'm new to this
stuff. Honestly I've never submitted a bug report before so I apologize if
I'm doing something outside of accepted protocol.

So, I ran "sudo update-rc.d rc.local defaults" and got the following reply:

System startup links for /etc/init.d/rc.local already exist.

So it appears that the link already exists. What strikes me as odd is that if
I manually run the script via /etc/init.d/rc.local start it runs fine.
Whatever is calling rc.local must be failing for some reason prior to the
actual running rc.local.

Unfortunately I have little knowledge of upstart, but what I'd like to do is
disable x so I can come right down to a command line and more easily watch the
boot process as it happens.

I installed a stock Hardy on a virtual machine and the rc.local ran fine. I'm
beginning to think this may not be a bug. The only reason I posted it is
searches.

Has anyone else been able to replicate the failing rc.local or seen other
references to it?

[Jason Thibeault (jthibeault-gmail)]

If you hit Ctrl-Alt-F8 at any time, you can switch to the console where the startup output is displayed -- on mine, the last line it shows is "* Running local boot scripts (/etc/rc.local) [ OK ]". I did not think to look at this when the problem was presenting for me. Does it show up on yours?

Hit Ctrl-Alt-F7 to get back to your X session, by the way.

[rignes (rignes-pobox)]

Actually, now that I've been poking at this, I realize that this really wasn't a bug. Though it seemed like it to me at first. Apparently the line where I was calling syndaemon to disable my touchpad while typing was bombing. Since it was at the top of the script it killed it and nothing else ran. As I've stated before, it worked fine when running rc.local start after the system was booted. The error was something to the effect that it couldn't find the display, which tells me it was running before x had a chance to get it's act together. I removed the syndaemon line and then the rest of the script ran fine.

I also used update-rc.d to remove all the symlinks and then put them back but I don't think that had any effect but I can't prove that one way or another.

So, I'd say this is an ID10T error on my part and not a bug at all.

Thanks for the help guys. I'll try to make sure I have a real bug next time I feel the urge to post one. ;)

[mindestens (bugs-launchpad-net-mindestens)]

the solution for editing the proc tree over rc.local might be using the following syntax in the rc.local file:

instead of
echo 1 > /proc/acpi/video/*/DOS
use this syntax:
for f in /proc/acpi/video/*/DOS; do echo 7 > $f; done

i got the solution from here:
http://bbs.archlinux.org/viewtopic.php?id=39840

it works fine for me.