Jessie: rc.local vs. systemd

[ontheair]

Hi everybody,

a big "thank you" to all the people who worked on the Jessie-release of Raspbian! Great work!
I made a dist-upgrade from Wheezy to Jessie and everything works like a charm. No problem at all.

There is just one question left: With systemd my old rc.local seems not to be executed at startup. In my case, I just added one line to my rc.local a long time before. Its the update deamon for TinyTinyRSS:

Code: Select all

sudo -u www-data screen -d -m /usr/bin/php /var/www/rss/update.php --daemon

Its not executed anymore on Jessie. So I have to find a way to get this simple command executed at startup. I have to admit that I have never worked with systemd before - and maybe its not necessary to learn everything of this complex system just for this one line that should be executed at startup.

Any ideas or hints to
- get the old rc.local working again
- or put the line somewehere else for execution at startup time?

Thank you for your help!

[Joe Schmoe]

There's another thread on this same topic (disguised as "Why doesn't it print out my IP address anymore?").

The consensus seems to be that rc.local does get run, but it runs very early (before the network is up - which means that you can't do anything network-y there anymore), and so you probably miss any output of it.

[firstness]

You could check some the information here:
http://blog.iopsl.com/rc-local-compatib ... rch-linux/

In particular:

Tip
You can also handle dependencies by modifying the .service file’s [unit] section to allow proper execution of stuff in /etc/rc.local.

Example
If /etc/rc.local is designed to connect Internet and do something to network interface, you can put After=network.target in the [unit] section, meaning it will only start AFTER network is configured.

[ontheair]

Joe, thank you for your reply!

Yes, I already followed this other thread. And it seems you are right: These two issues seems to have the same cause (executed too early). But anyway, in both cases we still dont have an idea for a workaround or solution.

I could imagine this sceanario:
- Deactivating the execution of rc.local by systemd
- Find another trigger to execute rc.local (maybe by crontab @reboot)

Just an idea. Im not a professional when it comes to this... So any help would be really appreciated!

[ontheair]

@firstness: Thank you for your help!
I am going to test this now and getting back if it works (or not)

[ShiftPlusOne]

You may want to use 'sudo journalctl' and 'sudo systemctl status rc-local.service' to see the output.

Example
If /etc/rc.local is designed to connect Internet and do something to network interface, you can put After=network.target in the [unit] section, meaning it will only start AFTER network is configured.

Unfortunately, that won't work with the current dhcpcd setup.

Systemd doesn't know when the dhcpcd service is 'done' (gets a lease). We've just been playing around a bit with this in the office and seem to have found a solution. Will try to get an update out as soon as it's more thoroughly tested.

[ontheair]

Thats also what I have seen now testing this workaround. After=network.target does not make any difference and the rc.local seems to be executed too early again.

If it helps, this is the output of "systemctl status rc-local.service -l":

Code: Select all

● rc-local.service - /etc/rc.local compatibility
   Loaded: loaded (/etc/systemd/system/rc-local.service; enabled)
   Active: active (exited) since Fr 2015-10-02 17:44:34 CEST; 5min ago
  Process: 347 ExecStart=/etc/rc.local (code=exited, status=0/SUCCESS)
 Main PID: 347 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/rc-local.service

Okt 02 17:44:32 10.0.42.3 sudo[348]: root : TTY=unknown ; PWD=/ ; USER=www-data ; COMMAND=/usr/bin/screen -d -m /usr/bin/php /var/www/rss/update.php --daemon
Okt 02 17:44:32 10.0.42.3 sudo[348]: pam_unix(sudo:session): session opened for user www-data by (uid=0)
Okt 02 17:44:32 10.0.42.3 sudo[348]: pam_unix(sudo:session): session closed for user www-data
Okt 02 17:44:34 10.0.42.3 systemd[1]: Started /etc/rc.local compatibility.

So it looks like all is fine, but the daemon (that should be executed by rc.local) is not active.
@ShiftPlusOne: I am looking forward to hear about the soultion you found!

[hippy]

Putting a printf "Within rc.local" within rc.local does show it is being run during boot-up and where. In my experience (Pi-B+), that output can still be seen on the TV when it reaches the CLI login prompt.

[firstness]

As a workaround what if you add "sleep 10" to rc.local above your command?

[ontheair]

Putting a printf "Within rc.local" within rc.local does show it is being run during boot-up and where. In my experience (Pi-B+), that output can still be seen on the TV when it reaches the CLI login prompt.

In my case the device is running headless, so I can not see it. But anyway, its beyond dispute that rc.local is executed (proofen by the output of systemctl status rc-local.service). Just the point in time is wrong.

I am really looking forward for ShiftPlusOne's ideas! In the meantime I will try to learn a bit about systemd - maybe there is a way to delay the execution or something like this...

As a workaround what if you add "sleep 10" to rc.local above your command?

Just have seen your reply right now Yes, a good idea. I will try this tomorrow when I am back!

[ShiftPlusOne]

I am really looking forward for ShiftPlusOne's ideas!

Don't want to take the credit for something I had nothing to do with; this was spl's fix. Will keep you posted.

[hippy]

As a workaround what if you add "sleep 10" to rc.local above your command?

That worked for me and my "My IP address is..." issue, delaying things until the dhcpcd client had run and obtained an IP address.

Added: It appears a fix is being worked on for these issues so possibly the best course is to wait for that unless there is an immediate need to try to get things working.

[ShiftPlusOne]

viewtopic.php?f=28&t=122066#p823749

[ontheair]

As a workaround what if you add "sleep 10" to rc.local above your command?

This is working. So its a great workaround!

viewtopic.php?f=28&t=122066#p823749

In this solution the dhcpd is launched by systemd instead of the traditional init script. I checked my setup again and remembered: In this case I am not using dhcpd. The Pi is configured with a static IP and dhcpd is not even installed. So this workaround is no option for me; I have to use the sleep-10-solution instead.

Added: It appears a fix is being worked on for these issues so possibly the best course is to wait for that unless there is an immediate need to try to get things working.

Are you talking about the dhcpd-startup-fix mentioned before or are there other solutions in the pipeline?

Just asking for information and curious purposes - right now I am happy with the delayed execution of rc.local.

[hippy]

Added: It appears a fix is being worked on for these issues so possibly the best course is to wait for that unless there is an immediate need to try to get things working.

Are you talking about the dhcpd-startup-fix mentioned before or are there other solutions in the pipeline?

Yes, that seems to be the fix. I don't know if it will fix everything and I haven't yet tried it but will and will report back. I believe it ensures dhcpcd is run before rc.local which means the temporary "sleep 10" to hold off rc.local execution can then be removed.

[danjperron]

Did you try to put your script in the crontab instead.

something like

Code: Select all

crontab -e
@reboot  sudo -u www-data screen -d -m /usr/bin/php /var/www/rss/update.php --daemon

[mntmst]

You can still install sysvinit, systemd-shim, sysvinit-utils and sysvinit-core if you still want init instead of systemd on your system.

[glreese]

Has there been an update to Jessie for this issue? I am experiencing the same problems related to execute timing of rc.local. Trying to boot to Kiosk - all worked w/ Wheezy. Will try the sleep 10 work-around - thank you for that guidance.

Thanks,

[ShiftPlusOne]

in raspi-config, "Wait for Network at Boot" -> " Slow Wait for network connection before completing boot"

[nl3prc]

I also have a problem with rc.local with jessie on te NOOBS system it work´s fine on jessie som of the commands don´t seem to load in my case kissattach is not workin when i enter the some executaqble on the command line it works
when in boot it up in rc.local some of the ax25 commands are not set

howe do i correct this error

[IgorGanapolsky]

I am having a similar issue on the latest Raspbian. I have a command in rc.local to start Ngrok. However, it doesn't start until AFTER I login. I don't understand, how can I make this command execute BEFORE I login?

[ccosse]

I solved rc-local.service startup issues by adding #!/bin/bash at top of /etc/rc.local

[dazz100]

My rc.local file already has

Code: Select all

#!/bin/sh -e 

on the top line.

rc.local fails with errors.

[dazz100]

Hello
A fail of rc.local is a significant bug.

I looked at other options, including daemontools. Then I found that daemontools start command is in rc.local, so that's no good.

My application is always on so a delay in starting apps after boot is not a big issue. At present, I have scripts running in crontab that check for specific apps running. eg. autossh. crontab is easy to use but rather crude.

A better solution might be to install upstart.

Dazz