Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

so I've been trying to get the /etc/rc.local script to run, and for the life of me, nothing seems to work. I can run it manually by using service rc.local start, and it just echos 'hi' to a file in my home directory, but on reboot it does not run. All the correct permissions seem to be set and links exist in the correct rc#.d directories. For reference, here is the relevant information:

# ls -l /etc/rc.local
-rwxr-xr-x 1 root root 45 Apr 12 21:10 /etc/rc.local

# ls -l /etc/init.d/rc.local                                  
-rwxr-xr-x 1 root root 812 Apr 12 21:00 /etc/init.d/rc.local

# for i in {0..6}; do cd rc$i.d ; pwd; ls -l |grep rc.local; cd ..; done
lrwxrwxrwx 1 root root  18 Apr 12 20:53 K20rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  18 Apr 12 20:53 K20rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  18 Apr 12 20:53 S20rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  18 Apr 12 20:53 S20rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  18 Apr 12 20:53 S20rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  18 Apr 12 20:53 S20rc.local -> ../init.d/rc.local
lrwxrwxrwx 1 root root  18 Apr 12 20:53 K20rc.local -> ../init.d/rc.local

# cat /etc/rc.local
#! /bin/bash

echo hi > ~user/test

exit 0

I've tried deleting both /etc/rc.local and /etc/init.d/rc.local, running update-rc.d rc.local remove, then restoring them and running update-rc.d rc.local defaults like in this question: Rc.local does not execute. That did not work.

It also does not work after reboot or entering any init level. It did not work when the shebang line read #! /bin/sh -e or #! /bin/bash. If I run it manually I can get both the /etc/rc.local and /etc/init.d/rc.local scripts to echo to different files, though.

So my question is...what am I doing wrong and how can I get rc.local to run? Also, while I don't mind hearing about alternatives (like upstart), I will only accept an answer that shows me (or helps me find) how to get rc.local to run normally (and ideally tells me what went wrong).

Here's some additional info for what it's worth:

# dmesg | grep "Linux version"
[    0.000000] Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 (Ubuntu 3.5.0-17.28-generic 3.5.5)

# cat /proc/version
Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012

# lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description:    Linux Mint 14 Nadia
Release:        14
Codename:       nadia
share|improve this question
Try echo hi > /dev/shm/test instead. – bahamat Apr 13 '13 at 5:38
That actually worked! So I guess the script is running but perhaps there is a problem with putting something in my home folder (maybe it's not mounted?). – atomictom Apr 13 '13 at 10:52
It would be mounted by the time rc.local runs. However, if the script before was exactly as shown, there is a typo: echo hi > ~user/test, (~user?) unless that was your edit. May also be something with permissions. – goldilocks Apr 13 '13 at 11:09
Oh, I changed it to ~user...but when I ran it manually it would create it in my home folder, so no typo...also wouldn't that mean there is no permission issue? – atomictom Apr 13 '13 at 18:59
up vote 0 down vote accepted

The problem is that in this line:

echo hi > ~user/test

~user isn't expanding as you expect. rc.local is running, but due to the unexpected expansion it's trying to write to someplace that it probably doesn't have permission for.

Try the following instead:

echo ~user/test > /dev/shm/test

Then check the contents of /dev/shm/test. This will both show that rc.local does run, and what it's expanding ~user to.

Although, my recommendation would be to use explicit paths, rather than relying on the external environment.

share|improve this answer
Well printing ~user/test into /dev/shm/test worked, and it printed the correct path to my home folder (/home/user/test), but doing echo hi > /home/user/test didn't work. Any idea why that wouldn't? Still, this worked to show me it was running, just not doing what I expected, so this answers the question, thanks! – atomictom Apr 21 '13 at 2:38
Try changing it to echo hi > /home/user/test 2>&1 > /dev/shm/log. Then check the log to see if there's any error message. There should be something. – bahamat Apr 21 '13 at 19:21
It just prints "hi" to /dev/shm/log. No error as far as I can tell. But the file /home/user/test does not exist. – atomictom Apr 28 '13 at 2:18

"I don't mind hearing about alternatives (like upstart)" implies you don't understand a couple of things. I'm not a mint user, but apparently it is an upstart based system. Upstart is an init daemon, and your system only has one installed. So upstart is not an alternative; there are no alternatives -- your system uses upstart. Period. It does not use anything else. However, upstart includes backward compatibility with sysvinit scripts, meaning you can manage services by placing links in /etc/rc directories and use some of the old commands like service and perhaps update-rc.d.

Since you don't by your own admission have much grasp of how that sysvinit system works, I think it is a waste of time for you to learn. You might as well learn how your real init daemon works. Upstart is pretty straightforward; keep in mind that 95% of the griping that goes on regarding it (and parallel grips about systemd on fedora derived systems) are just people who have a simple grasp of sysvinit and are mad that they might have to spend a couple of hours learning something new.

So, I would say to check the rc directories, etc, for the sysvinit style links, but from the look of the "Rc.local does not execute" question you linked to whose solution you say failed, I think you are wasting your time with that at this point. Forget sysvinit compatibility and the /etc/rc and init.d directories.

Upstart processes .conf files in /etc/init (note: not init.d). So, if you have some script you want run at boot, just add a .conf file to /etc/init. It does not have to be executable but it should be owned by root.

author "You"

start on started local-filesystems

    /etc/rc.local # but don't really be this lazy, see below
end script

To prevent future confuse and further sysvinit shenanigans, I recommend you change the name of the /etc/rc.local script to something else, or better yet, just move whatever's in it to the .conf file (everything between the script and end script tags is processed by the shell).

The definitive reference for upstart is probably the upstart cookbook. Like I said, it is an improvement, user friendliness wise, from sysvinit, but unfortunately there is still a paucity of decent material about it online, and a lot of confused and incomplete things. But to run a script at boot is as simple as just described.

If the .conf file is named "my-localboot.conf" you can test your service with

initctl start my-localboot
share|improve this answer
Oh, actually I was already aware of the Upstart/sysvinit difference and had actually looked through the upstart 'compatability' scripts to see where the were calling the sysvinit scripts (apparently I just worded that a bit wrong). Honestly, if I had a real service I wanted to start I would definitely be using Upstart...I just started with rc.local (for something that I later realized did not belong there) and then when I couldn't get it to work wondered why and then it bugged me more and more...until now I just want to understand why it does not seem to work. – atomictom Apr 13 '13 at 10:57
Sure -- I understand the desire to understand everything. But my point is that at this point in time, you are wasting your time learning about sysvinit. It is bound for complete depreciation. So if there is a problem, don't keep pounding your head against that wall -- get frustrated with the next generation of tools instead, lol. – goldilocks Apr 13 '13 at 11:02
Haha, yeah, I've mostly moved on, but that itch is still there to know what went wrong (and possibly learn something new I was not aware of). I actually didn't know much of anything about Linux a month ago...Either way, thanks for the info (especially the Upstart cookbook). I'll wait to see if anyone else has an answer for why it's not working before I choose an answer, but as soon as I have 15 rep I'll upvote you, either way. ;P – atomictom Apr 13 '13 at 11:08

Your Answer


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.