OSMC starts too fast - ignores sleep in rc.local file


I just reinstalled OSMC due to a failed SD card, and I am seeing some issue upon startup with my rc.local file. I have added a sleep command to wait 30 seconds followed by a VPN establish, but OSMC or the system itself atleast seems to be ignoring sleep and OSMC is immiediately loaded (Startup takes approx 15secs). This causes a addon to fail, due to a missing connection (Used via VPN)

I can confirm that the rc.local file is being started, by verifying that a file is written (For test purposes), and also that the VPN connection was established.

if i run /etc/rc.local while the system is already booted, it waits the number of seconds i defined in the sleep before it starts connecting to the VPN, but for some reason OSMC is still started without waiting the number of seconds defined in rc.local during a regular boot.

My /etc/rc.local file:

#!/bin/sh -e
#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
#By default this script does nothing.
sleep 30

echo "running rc.local" > /tmp/rc_test.txt

if [ $vpn = on ]; then
printf "\nVPN connection to VPN server\n"
sudo pon Myvpn updetach
printf "Add internet traffic route trough ppp0\n"
sudo route add -net "" dev "ppp0"
printf "Netstat output of all PPTP sockets\n"
netstat -a | grep "/var/run/pptp/"

exit 0

Does anyone have a clue why OSMC is still started up without waiting, when the system should be waiting 30seconds?

Thanks :slight_smile:

I think your script needs work. Try this:

echo "starting rc.local" > /tmp/rc_test.txt
sleep 30
echo "running rc.local after sleep" >> /tmp/rc_test.txt

to see if the sleep is working. And next:

if [ $vpn = on ]; then

should be

if [ $vpn = "on" ]; then


I have altered it as you advised (thanks about the vpn script part as well, it still worked for some reason).

OSMC still booted up in a few seconds. When it showed the OSMC picture, i reconnected to the Pi to check the /tmp/rc_test.txt and it was still missing the “running” part - only the starting part was written for now.

I added timestamps to the log, to clarify that it did sleep before continuing to write “starting rc.local…” (however more than 30), but OSMC still starts up before this text is even written.

osmc@osmc:~$ tail -f /tmp/rc_test.txt

starting rc.local Time: Fri Nov 30 08:49:11 CET 2018
running rc.local after sleep Time: Fri Nov 30 08:49:49 CET 2018

This part below shows that osmc was started at the same time as “starting rc.local” was written to rc_test.txt.

osmc@osmc:~$ systemctl status mediacenter

  • mediacenter.service - media center application
    Loaded: loaded (/lib/systemd/system/mediacenter.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2018-11-30 08:49:11 CET; 4min 54s ago


This is working as expected, All the sleep is doing is delaying the actions in rc.local. Mediacenter will run after network-online.target, this will not be changed by whats in the rc.local script.

Regards Tom.

I was sure this worked with my old install of OSMC.

So, a simple fix to delay OSMC startup could be to do a ‘systemctl disable mediacenter’, and add ‘systemctl start mediacenter’ in my rc.local at the buttom?

Not sure if it would work after a OSMC update, or if it will ignore the file.


Have you got wait for network enabled in myosmc?


1 Like

You could also add rc.local as a dependency to mediacenter.

Thanks. I added rc-local.service to the servicefile for Mediacenter, resulting in kodi/osmc not starting before the rc.local file finished it’s job. :slight_smile:

Just a warning. The moment you get an update to the mediacenter package, the service file will probably be overwritten.

1 Like

I would imagine so - in that event, i will just manually edit the file again (Atleast it asks before doing any updates :slight_smile: ).

I’m assuming that if i disable the service at startup, that it would be altered by the patches as well so for now i don’t see any permanent fixes.

That’s not a very good approach. The best way to do it is to create a systemd “drop-in”, which will not be overwritten by an update.

No. It will stay disabled, so your /etc/rc.local method should work after an update.