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.


EDIT: no quatation marks used

  • Is the path /home/smart-scale/scoreboard/main.py definitely correct?
    – CoderMike
    Jan 22, 2019 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, 2019 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. Jan 22, 2019 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, 2019 at 11:47
  • Since you accepted a cron answer, your question is essentially a dupe of Execute script on start-up Jan 25, 2019 at 13:27

4 Answers 4


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, 2019 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, 2019 at 21:15

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

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, 2019 at 23:00

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.

  • 1
    In general it is not a good idea to ride a dead horse with rc.local.
    – Ingo
    Sep 12, 2020 at 16:52
  • Now that I have grasped the character limit concept, recounted above, which had caused me considerablr grief, I find that rc.local is far from dead, but is in fact quite useful and reliable for starting "headless" Raspi projects.
    – user86687
    Sep 12, 2020 at 17:07
  • 1
    Please understand the last sentence at Compatibility with SysV, saying: "Note that there are some areas where systemd currently provides a certain amount of compatibility where we expect this compatibility to be removed eventually."
    – Ingo
    Sep 12, 2020 at 17:28
  • What you have 'grasped' is an incorrect notion. rc.local is not long for this world; whatever utility it once had is being slowly but surely removed. If you want to continue to use it, I'd suggest you find a 15-year-old distribution of FreeBSD. Not meant to be rude or insulting - we're just trying to share the facts with you. If you don't like the facts, we understand - but facts are facts.
    – Seamus
    Sep 13, 2020 at 0:06
  • Have you not noticed that this thread is about the Raspberry Pi, so references to 15 year old FreeBSD are not awfully useful, relevant or based on facts.
    – user86687
    Sep 13, 2020 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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