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

Question

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?

Solution 1

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.

Solution 2

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

Solution 3

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

Solution 4

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.

Solution 5

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

rc.local         [ ]   [x]   [x]   [x]   [x]   [ ]   [ ]   [ ]

View more solutions

Comments

[x-x]

Yes, it is enabled.

[Qian Chen]

Thank you. sleep 1 solved my problem. Interesting I have a lot of servers but only one has this problem.

[jcollum]

does this command need to be installed?

[Rıfat Erdem Sahin]

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.

[muru]

You don't need to manually enable the service. If the file exists and is executable, systemd will automatically enable the rc-local service.

[user639188]

@jcollum yes, it is a program from a package named the same. To install, type sudo apt install sysv-rc-conf

[bomben]

rc.local is not even in my list of services!

[bomben]

I am also getting this error. If rc.local is turned off, what is the alternative?

[Mohith7548]

Please tell me what does the step-4 does? I'm new to update-rc.d

[sureshvv]

Do sudo /etc/rc.local and make sure it works.