0

I'm trying to ran python 2.7 script on boot, and did following:

  • sudo nano /etc/rc.local
  • Modified file before exit 0 with line:
  • sudo /usr/bin/python /home/smart-scale/scoreboard/main.py &
  • That command works on ssh terminal
  • Added "#!/usr/bin/python" to the top of script

When I reboot and check if its running with htop, it's not.

Ideas?

EDIT: no quatation marks used

  • Is the path /home/smart-scale/scoreboard/main.py definitely correct? – CoderMike Jan 22 at 20:55
  • 1
    rc.local is an unreliable way of running a script. You do not use sudo, and no one can tell what you are trying to do. – Milliways Jan 22 at 20:55
  • Does the command-line that you typed into the /etc/rc.local file include the quotation marks? If so, remove them. Having them in a shell script such as /etc/rc.local will cause the entire line to be perceived by the shell as a single command with a very long and unusual name. – Jeremy Impson Jan 22 at 20:59
  • @CoderMike The path is correct as the command works when running through ssh terminal. There is no quatation marks – dev-1000 Jan 23 at 11:47
  • Since you accepted a cron answer, your question is essentially a dupe of Execute script on start-up – Dmitry Grigoryev Jan 25 at 13:27
1

As @Millways has pointed out in his comment, using rc.local is probably not the best way to do this. You should try something else. There are two alternatives (maybe more); I'll describe one of them here; the one I feel is the simplest and easiest:

Start your crontab editor as follows:

crontab -e 

Add the following line to your crontab file:

@reboot /usr/bin/python /home/smart-scale/scoreboard/main.py 

Depending upon the resources required in your Python script, and the timing of related events in the boot process, you may find that your script does not run with this crontab entry. If that's the case, simply delay execution of the script to give all the required resources to get up and running using the sleep directive as follows:

@reboot /bin/sleep 30; /usr/bin/python /home/smart-scale/scoreboard/main.py 

It may also be helpful to redirect the stderr output (error messages) to a file (/home/pi/cronjoblog in this example) for diagnosis and debugging. You can do that by this simple addition to the same line in your crontab file:

@reboot (/bin/sleep 30; /usr/bin/python /home/smart-scale/scoreboard/main.py  > /home/pi/cronjoblog 2>&1) 

Once you've finished your edits to the crontab file, save and exit. When you reboot, your script will run.

  • thank you @Seamus! This one worked. It might have been because of the delay, as the script is trying to connect to a usb device. But i will definetly use this crontab method going forward – dev-1000 Jan 23 at 14:26
  • @dev-1000: I'm glad it helped. But before becoming too attached to cron, you should spend some time learning about systemd as it's the "new way", and has some distinct advantages over cron. ALSO: Please read this. – Seamus Jan 23 at 21:15
1

The most likely reason is that environment variables are missing, such as PYTHONHOME.

Try to start your script from the command line with

env -i sudo /usr/bin/python /home/smart-scale/scoreboard/main.py

Add missing variables to the script until it runs.

For a list of Python related environment variables, use

env | grep ^PYTHON | sort
0

I assume your /etc/rc.local file does not contain the literal quotation marks that you surrounded your command-line with in your question. If so, remove them; they are the problem.

I also assume you've used the search feature in htop to confirm that the process is definitely not running. If you only look at the default view, htop sorts processes according to how busy they are. It's possible your script is running but is blocked for some reason (such as waiting for input). If so, it might not show up near the top of your list.

If your script is definitely not running, or if it is running but not doing whatever you want it do do, one debugging tip is to capture the output and error messages into a file so that you can read it after it has run and (presumably) failed. Note that the syntax is very particular. Don't use quote marks, and make sure you preserve the spaces as follows.

sudo /usr/bin/python /home/smart-scale/scoreboard/main.py > /tmp/scoreboard.log 2>&1 &

The first part of the command has your original command line, minus the & at the end.

The > /tmp/scoreboard.log part is a shell redirection and it causes any printed output from your program to be captured (redirected) to a file called /tmp/scoreboard.log. I made up that name, you can change it to whatever you like. It should be a complete fully-qualified file path, though.

The 2>&1 part is a different kind of redirection that causes error messages to also be captured in the same file as the output messages, in order of occurrence with the output messages.

The final & puts the command in the background just as you had in your original command line.

Reboot and use nano, cat, or less to check the contents of the file /tmp/scoreboard.log. With luck it will tell you what is wrong and you can correct it. If you don't understand what the output means, update your question with the output and we'll try again.

P.S. Note that this debugging command is for troubleshooting only; if you leave this change in indefinitely, you might fill up your disk with logging data.

P.P.S. A couple other comments that probably have nothing to do with your problem.

First, the use of sudo in /etc/rc.local commands is not needed, as everything run from rc.local is already run as root. It's harmless to leave in, but I recommend removing because later on you may wonder why it's there.

Second, you don't need #!/usr/bin/python (which is called a bang path) in your python script file since you are explicitly calling /usr/bin/python on the command line. You could remove the bangpath from the python script, or you could leave it in and remove the explicit call to /usr/bin/python in the rc.local script. If you do the latter, you have to make sure the script it executable (chmod a_x /home/smart-scale/scoreboard/main.py). If all of that is new to you, don't worry too much. Leaving it as-is is not hurting anything, and in fact is quite common. I just wanted to let you know they are two different ways to get the same effect, i.e. to get your script run by a python interpreter.

  • In addition to any debugging suggestions you should be aware that using /etc/rc.local may have timing problems in general with unexpected side effects. This is because rc.local is only emulated by systemd. Look at Compatibility with SysV for its limitations. – Ingo Jan 22 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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