/etc/rc.local is not executed at startup

Bug #882254 reported by dorpm on 2011-10-26
This bug affects 15 people
Affects Status Importance Assigned to Milestone
sysvinit (Ubuntu)

Bug Description

/etc/rc.local is not executed at startup in 11.10. In 11.04 this was not the case. Is there any alternative?


ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: upstart 1.3-0ubuntu10
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Wed Oct 26 22:15:00 2011
 PATH=(custom, no user)
SourcePackage: upstart
UpgradeStatus: Upgraded to oneiric on 2011-10-24 (2 days ago)

dorpm (dorpmueller) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in upstart (Ubuntu):
status: New → Confirmed
julien (julien-briche) wrote :

I am quite a newbie in fixing bugs in Ubuntu, but as I deeply needed this feature I had to put my fingers in the mud...
So here is the new file /etc/init.d/rc.local I modified and it works, at least for what I meant to do (in fact the -x didn't worked so I put -e and I forced the execution of /etc/rc.local by adding sh in front ).

#! /bin/sh
# Provides: rc.local
# Required-Start: $remote_fs $syslog $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Run /etc/rc.local if it exist


. /lib/init/vars.sh
. /lib/lsb/init-functions

do_start() {

 if [ -e /etc/rc.local ]; then

         [ "$VERBOSE" != no ] && log_begin_msg "Running local boot scripts (/etc/rc.local)"
  sh /etc/rc.local

  [ "$VERBOSE" != no ] && log_end_msg $ES
  return $ES


case "$1" in
        echo "Error: argument '$1' not supported" >&2
        exit 3
        echo "Usage: $0 start|stop" >&2
        exit 3

hope it will help someone...

efzwo (efzwo) wrote :

thanks to julien, your change does the trick

efzwo (efzwo) wrote :

what i forgot to report:
the problem only occured if the notebook (Acer Aspire 4820) is booting on battery without ac adapter.

Steve Langasek (vorlon) wrote :

/etc/rc.local is run from /etc/init.d/rc.local via the /etc/rc2.d/S99rc.local symlink, which is all part of the initscripts package. Are these files missing from your system for some reason? Or, like Julien, is your /etc/rc.local not executable? (I think that would be considered a configuration error - /etc/rc.local has always been expected to be a script, AFAIK.)

affects: upstart (Ubuntu) → sysvinit (Ubuntu)
Changed in sysvinit (Ubuntu):
status: Confirmed → Incomplete
Raimund Hölle (privat3) wrote :

I can confirm this bug.

The reason is simple: /etc/rc.local isn't executable after installation.

So chmod -x /etc/rc.local makes the trick.

Regards, Raimund

Steve Langasek (vorlon) wrote :

> The reason is simple: /etc/rc.local isn't executable after installation.

When installing how, with what version of Ubuntu? This bug was reported against Ubuntu 11.10. The initscripts package in Ubuntu 11.10 includes an /etc/rc.local file that is marked executable.

> So chmod -x /etc/rc.local makes the trick.

No, that does the exact opposite of what you want.

Raimund Hölle (privat3) wrote :

> When installing how, with what version of Ubuntu?

Same Version as reported by Florian, see bug description: 11.10 amd64

> This bug was reported against Ubuntu 11.10. The initscripts package in Ubuntu 11.10 includes an /etc/rc.local file that is marked executable.

I don't know whats marked as whatsoever - but after installation of Ubuntu 11.10 (x86_64) it is possible that /etc/rc.local is not executable.

I've double checked that in the moment by performing two identical fresh installations on different hardware and it seems to be a strange behaviour:

* HP EliteBook 8560p, i5-2540M, SSD: NOT executable
* Virtual machine (VMware ESXi): executable

Installations were done by booting the live CD per PXE, then performing "apt-get upgrade".

>> So chmod -x /etc/rc.local makes the trick.
> No, that does the exact opposite of what you want.

Right, it's a typo, correct is: chmod +x /etc/rc.local

Chad Williams (chazinams) wrote :

I'm suffering from this bug in 12.04.

Using Lenovo X220 laptop. I installed 12.04 on it.

Every time I boot the display's brightness sets to the highest setting: max_brightness = 15. This is way too bright and want to set it to 3.

I have spent a long time trying to fix this. Tried editing rc.local file by adding the "echo 3 >" line before exit 0. But it never works. laptop always resets to level 15 after boot. I tried everything here: http://askubuntu.com/questions/3841/desktop-doesnt-remember-brightness-settings-after-a-reboot

Does anyone know how I can edit the maximum_brightness down? Can I set a lower maximum_brightness?

Chad Williams (chazinams) wrote :

I stole above description from another Ask Ubuntu question (in case it matters).

Lindsey334 (lindtine334) wrote :

Hi, guys ;)

Julien's hack of the rc.local file in the init.d directory did not work for me. I booted several times after making the change and one time it did boot with reduced brightness. But all other times Max Brightness was always on. I have no idea why it booted with reduced brightness that one time. I tried replicating with boot on battery, boot with power connected, but all those other times I got Max Brightness. I dealing with a stock 12.04 install so there's no chance I bonked something from a configuraton error.

I checked my rc.local files and they are all marked as executable by root.

Is there any way to get an Ubuntu Developer to fix this? This is a serious bug. I mean booting at Max Brightness on battery seriously drains the battery causing heat as well with increased fan speed. And Max Brightness artificially wears down the Display's health. I think this should be considered a serious bug that deserves "professional" attention to fix, especially for LTS quality.

I would be most appreciative of any ideas on how to fix this. I really want to fix it. What can I do now? Please advise, thank you.

Steve Langasek (vorlon) wrote :

I have no idea why people are following up to this bug with questions about max brightness all of a sudden, but this is a bug report about /etc/rc.local not being marked executable. If your /etc/rc.local file is not executable, then you may be seeing this bug - in which case it would be helpful if you would provide more information about how /etc/rc.local came to not be executable on your system, since we can't reproduce this.

However, it is much more likely that the problem you're encountering is not due to /etc/rc.local failing to execute at startup, but instead due to your rc.local not being configured to do what you actually want. You should test that the proposed command does anything at all by running it at the command line:

    echo 0 > /sys/class/backlight/acpi_video0/brightness

If you can't get it to work at the commandline, you definitely won't get it to work from rc.local. And even if you get it to work at the commandline, this setting may be getting overridden by the desktop after rc.local runs.

But unless 'ls -l /etc/rc.local' shows that the file is not executable, please do not send further follow-ups to this bug report. The askubuntu question is a much more appropriate place to discuss.

Lindsey334 (lindtine334) wrote :

Steve Langasek:

People are following up this bug because nothing has been done about it.

YES, the proposed command: echo 0 > /sys/class/backlight/acpi_video0/brightness works when I run it in command line (Terminal). In fact, I execute this command EVERY SINGLE TIME I start my dang computer to get the brightness level to something that isn't going to melt my eyeballs. It is hugely inconvenient.

So since it works at the command line, I don't understand why it is not working in the rc.local file. Hence = bug.

And YES the rc.local file is marked as executable. This is actually the first thing I checked when I noted it wasn't working.

Is there anything else I can do to get rc.local working please or to get someone to address this bug please?

By the way, this issue has already been posted on AskUbuntu with zero help provided. In fact, a link to the question has already been posted in this comment thread.

Thanks, looking forward to your response.

Lindsey334 (lindtine334) wrote :

Assuming rc.local is getting overridden by the desktop, is there a way to make it execute again after the desktop has overridden it?

Matt Miller (paintitmatt) wrote :

Ubuntu 12.04

I'm having the same problem, and got here via a screen brightness problem as well.

I can run
/etc/rc2.d/S99rc.local start
/etc/init.d/rc.local start

and the screen dims each time

so it's not the file(s) or the permissions (I checked they're all executable by root).

So I'm assuming /etc/rc2.d/S99rc.local start isn't running at startup.

Matt Miller (paintitmatt) wrote :

Actually, rc.local *is* running for me, it's just not executing the screen dimmer command...

I put

touch /home/<my account>/Desktop/rc-local-ran

at the top of rc.local. I had the file on my desktop when I logged in.

So it looks like I'm going down a different rabbit hole now.

Matt Miller (paintitmatt) wrote :

hmmm well... something is weird.

touch /home/<my account>/Desktop/rc-local-ran1
xbacklight -set 20
touch /home/<my account>/Desktop/rc-local-ran2

puts file 1 on my desktop, not file 2

I had this issue and post 2 did not help. I recently upgraded from MythBuntu 11.04 -> 11.10 -> 12.04 and found rc.local not executing, or so I thought.
I ran it manually and received an error:
/etc/rc.local: 18: /etc/rc.local: cannot create /sys/module/drm_kms_helper/parameters/poll: Directory nonexistent

So I removed line 18 from rc.local and the problem was solved.
The problematic line was:
echo 0 > /sys/module/drm_kms_helper/parameters/poll

Dylan Howey (howey014) wrote :

@Matt Miller:

The shebang in the rc.local script reads "#!/bin/bash -e", where the "-e" means that the script will immediately stop if any command in the script fails. The fact that file 2 did not appear on your desktop means that there was a problem with your "xbacklight" command.

Some playing around shows that rc.local runs pretty early on compared to other things when the system is booting. It's completely possible that you're trying to run "xbacklight" too early (e.g., the X server probably hadn't even started yet) and it had failed as a result.

Try putting a short pause before you run that command; do this by adding the line "sleep 30" before the line where you're trying to dim the screen. This tells the machine to wait 30 seconds (or whatever amount of time you want) before moving on to the next line of the script. I'm willing to bet that this will fix the problem that you're having, as well as Lindsey334's and Chad William's.

Launchpad Janitor (janitor) wrote :

[Expired for sysvinit (Ubuntu) because there has been no activity for 60 days.]

Changed in sysvinit (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers