Python script not running on boot from /etc/rc.local

Question

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

Answer 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.

Answer 2

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

Answer 3

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.

Answer 4

I struggled with using etc/rc.local to run a python script at startup for several months. Nothing happened with no error messages. It seems that there is limit to the number of characters you can have in the path/filename string, just as there was in MSDOS. (ducks from a clap of thunder and a deluge of locusts). It is about 32 characters. Life is too short to be more specific. Shortening the filename, which had grown like topsy during development, but which hadn't caused Python to choke, did the trick in my case. Your line "/home/smart-scale/scoreboard/main.py" is 36 characters long, and will certainly fail, if my theory is correct. Test the line you intend to put into rc.local in a Terminal window. If it doesn't work there you will at least get the error message that the file can't be found. If it does work there then it will/should work in rc.local.