1

I want to run some script at bootup, right now I'm trying to see if can achieve this using rc.local is this even a good practice??

To try out this script that it's supposed to run at bootup I'm am trying to run it just with the default code that comes within the scriptThe one that prints the IP address). The problem is that when I run this script manually it works perfectly even if I put some other scripts and I run this one everything seems okay the problem is at bootup it doesn't work.

I'm trying to fix this and after two days of research I've learned some things if reboot the pi and run :

sudo systemctl status rc-local

there are errors and the console displays that the operation has failed in red letters because of some compatibility error. Is there a problem with the OS? I'm using the latest version of raspian (STRECH).

rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static)
   Active: failed (Result: exit-code) since Mon 2016-01-25 18:16:55 CET; 3min 49s ago
  Process: 378 ExecStart=/etc/rc.local start (code=exited, status=203/EXEC)

Jan 25 18:16:55 pocketvj-100 systemd[1]: rc-local.service: control process exited, code=exited status=203
Jan 25 18:16:55 pocketvj-100 systemd[1]: Failed to start /etc/rc.local Compatibility.
Jan 25 18:16:55 pocketvj-100 systemd[1]: Unit rc-local.service entered failed state.

Also, I got the warning that suggests us to run:

sudo systemctl daemon-reload

so I did it and it didn't work out for me.

I also verified if this script was even executable and it was, using

ls -l

I got this:

 -rwxr-xr-x

and as far as I know, this is okay.

  • Is this compatibility error possible to fix?
  • rc.local good practice?
  • Should I better try systemd workaround or crontab?
  • what are the best practices?
Ingo
  • 42,107
  • 20
  • 85
  • 197

3 Answers3

1

using rc.local is this even a good practice

Yes, and it is probably the simplest and easiest one. It is, however, not completely foolproof.

I'm am trying to run it just with the default code that comes within the scriptThe one that prints the IP address

That default is a peculiarity of Raspbian and has been there for a long time. I'm not quite sure what the point of it ever was because something printed to console during boot is very hard to catch, and impossible if you are using a graphical boot.

Something to note here is that this won't happen if the system hasn't gotten an IP address yet:

_IP=$(hostname -I) || true
if [ "$_IP" ];

The essentially pointless || true may obfuscate that (it just sets the exit status to 0, which it would have been anyway since there is an explicit exit 0 here too); in any case it is possible (or most probable) that the test will fail because there is no IP address to print.

because of some compatibility error

I think you are misinterpreting this line:

Failed to start /etc/rc.local Compatibility.

This is just referring to the service itself. The rc.local file is really a relic of SysV init, and systemd's rc-local.service implements compatibility with it's traditional use.

A little bit of searching online implies the 203/EXEC status means the script did not run because:

  • It is not executable (but you seem to have ruled this out).
  • The shebang is messed up; this is the first line that should be #!/sh -e (it could be other things too but that is the default). A possibility is that editing it on a Windows machine screwed up the line endings, which are significant there.

    A somewhat more robust shebang is #!/usr/bin/env bash. See if that helps.

The problem is that when I run this script manually it works perfectly even if I put some other scripts and I run this one everything seems okay the problem is at bootup it doesn't work.

Because it runs from the command line does not mean it will fly via init. For starters, whatever you are doing should not remain in the foreground for more than a second or two. It also should not require a GUI context, and should not make much (really, any, contra the Rasbpian "print IP") use of the standard output or error stream.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • Okay, thanks for all of your help I'm a noob here but I really wanna get to know this stuff based on your help I tried to fix my problem and it was very simple, now when I check in sudo systemctl status rc.local I get positive feedback even though the warning message keeps showing up everything is shown in green letters instead of the red ones. For now, I'm running a simple script that just prints that everything is working fine. I want to run Thonny IDE whenever the Pi boots up so this is the code in the script (very basic) – Carlos Echeverria St Jul 09 '18 at 00:22
  • echo "running rc.local" this works good but if I put on next line thonny it opens the Thonny IDE only if I run it manually when everything is already loaded but on boot, this is an error and rc.local doesn't run, so how can I correctly achieve this functionality. I've already tried a few things but they didn't even work when I run the script manually so I tried just typing in"thonny" and it work but not on bootup. Thanks for your help. – Carlos Echeverria St Jul 09 '18 at 00:30
  • The way to start a foreground GUI app at boot on Raspbian using PIXELis via /home/pi/.config/lxsession/LXDE-pi/autostart: https://raspberrypi.stackexchange.com/a/85214/5538 – goldilocks Jul 09 '18 at 11:39
  • Thank you so much I will take a look and see what happens! c: – Carlos Echeverria St Jul 09 '18 at 14:12
1

Debian like most other distributions has decided to replace the old style SysV init system with systemd because it fits better to modern multi core / multi processor machines. This way systemd comes also to Raspbian since Raspian Jessie. Because this is the upcoming system I have decided for me to use it consequent. So I would answer your questions:

Is this compatibility error possible to fix?

As @goldilocks already stated this is only the name of the systemd unit that emulates old style SysV behaviour for compatibility.

rc.local good practice?

rc.local is emulated by systemd. I believe it is less error prone to use the original than the emulation. You just make the experience.

Should I better try systemd workaround or crontab?

systemd isn't a workaround. Things are made by systemd. All others are workarounds.

what are the best practices?

That is your decision. I will give you an example to start your program with a systemd unit.

Create a new systemd unit with:

rpi ~$ sudo systemctl --force --full edit thonny.service

In the editor insert these statements, save it and quit the editor:

[Unit]
Description=Service to start thonny
Wants=graphical.target
After=graphical.target

[Service]
User=pi     # or must it run as root? Then omit this line
ExecStart=/home/pi/thonny   # or where your program is

[Install]
WantedBy=graphical.target

Enable the new service:

rpi ~$ sudo systemctl enable thonny.service

reboot.

Check with:

rpi ~$ systemctl status thonny.service
rpi ~$ systemctl cat thonny.service

Edit again with:

rpi ~$ sudo systemctl --full edit thonny.service

I don't know if it runs on the first attempt. There may be some edge conditions I don't know, something like user rights, environment etc. It is no problem to configure these dependencies. The problem is to find them ;-)

Ingo
  • 42,107
  • 20
  • 85
  • 197
  • Thanks a lot, you did a great job in your answer! So this new thonny service is going to run when? at boot up ?? c: – Carlos Echeverria St Jul 13 '18 at 15:37
  • @CarlosEcheverriaSt yes it is started as a service (daemon) at startup After the GUI is up (graphical.target). You can start it earlier, maybe After display-manager.service? systemd-bootup – Ingo Jul 13 '18 at 20:22
0

I usually don't mess with services, init, or anything like that. I simply place a cron entry that runs at boot.