37

I have a single command in my /etc/rc.local script that is supposed to start the update daemon for Tiny Tiny RSS during startup, but the script is not executed during startup. Why?

The entire /etc/rc.local file:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/sbin/start-stop-daemon -b -c www-data:www-data -S -x /usr/bin/php /var/www/ttrss/update_daemon2.php -- -quiet

exit 0

/etc/rc.local is executable:

# ls -l /etc/rc.local
-rwxr-xr-x 1 root root 342 May 25 16:14 /etc/rc.local

/etc/init.d/rc.local exists and is executable:

# ls -l /etc/init.d/rc.local
-rwxr-xr-x 1 root root 801 Jul 27  2012 /etc/init.d/rc.local

/etc/init.d/rc.local is supposed to be executed at startup for this runlevel:

# runlevel 
N 2
# ls -l /etc/rc2.d/S99rc.local 
lrwxrwxrwx 1 root root 18 Sep 22  2012 /etc/rc2.d/S99rc.local -> ../init.d/rc.local

If I manually call /etc/rc.local from the command line the update_daemon loads...

# /etc/rc.local
# ps ax | grep update_daemon2.php
2233 ?        S      0:00 /usr/bin/php /media/sda5/www/news/update_daemon2.php -quiet
2234 ?        S      0:00 /usr/bin/php /media/sda5/www/news/update_daemon2.php -quiet

... which I have to remember to do every time my server restarts until this problem is fixed.

Similar questions already exist, but so far I've been unable to apply the information within to my specific problem.

Why is the command in rc.local not executed during startup?

  • May be due to the requiretty setting. When you are logged-in, you are executing the script in TTY but during the system boot, it is not in TTY. This link may assist you shell-tips.com/2014/09/08/… Thanks. – KICT Oct 24 '17 at 12:58
22

rc.local script exits if any error occurs while executing any of its commands (mention the -e flag in #!/bin/sh -e).

It is possible that some prerequisites are not met when you try to run your commands when rc.local execution takes place, so your command execution fails.

I encountered the same thing while manually setting cpu governor and failing to do so in rc.local. Here's my custom workaround, which uses update-rc.d to make your commands run on startup:

  1. Create a file myscript.sh in directory /etc/init.d with a heading: #!/bin/sh
  2. Put your custom commands as the content
  3. Make it executable: sudo chmod +x /etc/init.d/myscript.sh
  4. Create symlinks for your script for various runlevels: sudo update-rc.d myscript.sh defaults

Also, you could check /etc/network/if-up.d scripts and see if you could trigger your commands when networking starts.

  • Thank you for the answer. My setup has changed since I posted the question, so I am unable to test if your answer would have solved the problem. – x-x Mar 9 '14 at 8:24
5

try sudo sysv-rc-conf and check out if rc.local is enabled

rc.local         [ ]   [x]   [x]   [x]   [x]   [ ]   [ ]   [ ]
  • Yes, it is enabled. – x-x May 25 '13 at 23:54
  • does this command need to be installed? – jcollum Aug 12 '17 at 1:43
  • 1
    @jcollum yes, it is a program from a package named the same. To install, type sudo apt install sysv-rc-conf – banan3'14 May 28 '18 at 17:31
5

i had some similar problem in rc.local not executing at startup

sshades provided me with the following answer :

Ubuntu is now using systemd, and rc.local is now considered a service which is turned "off" by default. You can turn rc.local "on" by entering the following command and rebooting:

sudo systemctl enable rc-local.service

https://askubuntu.com/a/770033/395498

although i haven't tested his solution i think it sounds logical and will work. However :

I also found a solution that adding a script to ./.config/autostart-scripts/ will do the trick

  • 6
    Getting this error . The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. – Rıfat Erdem Sahin Nov 2 '17 at 19:26
4

Make sure the rc.local script is executable:

sudo chmod +x /etc/rc.local

Then, enable it:

sudo systemctl enable rc-local.service

Reboot the system or start the script manually by running:

sudo systemctl start  rc-local.service

The service status can be displayed by running:

$ sudo systemctl status rc-local.service
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled) 
Drop-In: /lib/systemd/system/rc-local.service.d
           └─debian.conf
   Active: active (running) since Mon 2018-04-02 10:39:44 -03; 1s ago
  Process: 2044 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)
 Main PID: 2049 (svscanboot)
Tasks: 3
 Memory: 556.0K
CPU: 10ms
CGroup: /system.slice/rc-local.service
  • You don't need to manually enable the service. If the file exists and is executable, systemd will automatically enable the rc-local service. – muru Apr 2 '18 at 13:55
3

We had this problem on some hosted servers loading FW rules.

On these boxes they reboot VERY quickly and we found just putting a "sleep 1" in rc.local before the load statements seems to fix the issue. I guess it gave a little time for the interfaces to settle before loading the FW rules.

  • 1
    Thank you. sleep 1 solved my problem. Interesting I have a lot of servers but only one has this problem. – Qian Chen Jan 20 '16 at 19:24
1

I once edited rc.local with Notepad in Windows and it began to have this problem.

In this case, using a text editor supports EOL Conversion, such as Notepad++, to convert the EOL style to 'Unix', may solve it.

You can also do it by :set ff=unix in Vim.

1

I found in Ubuntu lxc containers that if rc.local has a perfectly correct shebang e.g.

#!/bin/sh

it fails, but if you remove the shebang it works.

Not got to the bottom of why or what shell it uses I think it bombs on first non-zero too. (In other Ubuntu installs proper shebang is not an issue)

0

You will have to make sure that /etc/rc.local is executed during the server startup with the command:

sudo systemctl enable rc-local.service

protected by Community Apr 13 '18 at 17:00

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.