0

I have edited rclocal to include this line:

python3 /path/to/my/program.py &

I used an ampersand as my program has an infinite loop.

The program never runs though.

The program:

import RPi.GPIO as GPIO
from time import sleep
from datetime import datetime
import glob, sys, vlc, random

pir = 4
led = 24

GPIO.setmode(GPIO.BCM)
GPIO.setup(pir, GPIO.IN)
GPIO.setup(led, GPIO.OUT)

files = glob.glob("/home/pi/sad/*.mp3")

if len(files) == 0:
    # todo: flash led
    print("No mp3 files found. Exiting")
    sys.exit(1)

random.shuffle(files)

player = vlc.MediaPlayer()
media_list = vlc.MediaList(files)
media_list_player = vlc.MediaListPlayer()
media_list_player.set_media_player(player)
media_list_player.set_media_list(media_list)


def play_audio(channel):
    if media_list_player.is_playing():
        return
    print("Movement detected: " + str(datetime.now()))
    media_list_player.play()


print("Detecting...")

try:
    GPIO.add_event_detect(pir, GPIO.RISING, callback=play_audio)

    GPIO.output(led, GPIO.HIGH)

    while True:
        sleep(100)
except KeyboardInterrupt:
    print("Exiting...")

GPIO.cleanup()

Where would I find the error files to see why it might be going wrong?

As a side note, I have tried a few ways to get this program to run on boot and nothing works.

The program is a very simple 'burglar alarm', fun project which uses a local speaker and a PIR sensor.

Any help would be appreciated at this point.

Edit If I run another file which just flashes an led, it boots and runs fine:

import RPi.GPIO as GPIO
from time import sleep

led = 24

GPIO.setmode(GPIO.BCM)
GPIO.setup(led, GPIO.OUT)

try:
    GPIO.output(led, GPIO.HIGH)

    while True:
        sleep(101)
except KeyboardInterrupt:
    print("Exiting...")

GPIO.cleanup()

I have literally no idea why the led ones boots and runs fine but the pir/audio one doesn't.

3 Answers 3

1

Not sure how quickly you want the program to start after boot but I use the following code in a bash file to start a python3 daemon:

starttest.sh

sleep 10
nohup python3 -u /home/pi/bin/test.py  > "/tmp/nohup.out" &
pid=$!
echo "kill $pid" >/tmp/killpopup.sh

and I start it from a .desktop file in /home/pi/.config/autostart containing :

starttest.desktop

[Desktop Entry]
Name=Start Test
Type=Application
Exec=bash /home/pi/bin/starttest.sh

I monitor the output to /tmp/nohup.out by issuing the command tail -f /tmp/nohup.out in a terminal window.

I am getting stdout into the file but not sure about stderr because I can't quickly simulate an error but I usually use print statements for debugging in any case. But this may be useful to get you started.

There is also a python-daemon package you can import especially designed for python daemons but I have not tried it.

0

rc.local is an obsolete SysV concept and should not be used to start programs. There are dozens (if not hundreds) of similar questions with suggested solutions.

Without knowing what your program is supposed to do it is impossible to say which you should use.

7
  • As l posted, l tried a fair few (although l didn't admittedly get into triple figures). Also, the program is very simple - a pir senses movement, then a speaker plays audio.
    – Leon Segal
    Mar 11 at 21:38
  • I edited the question to show both programs - one working on boot and one not for some reason
    – Leon Segal
    Mar 11 at 21:44
  • @LeonSegal at the very least ANY program run at boot NEEDS full paths and can not do any terminal output.
    – Milliways
    Mar 11 at 21:44
  • the terminal output is not needed it's purely for debugging. What do you mean about full paths? Did you mean the audio files?
    – Leon Segal
    Mar 11 at 21:49
  • Boot code doesn't know where python3 is. I suggest you forget rc.local and use cron. You should study some of the answers to similar questions which explain this.
    – Milliways
    Mar 11 at 21:54
0

As @Milliways said, the first rule is, "Don't use rc.local" because it is deprecated, and its behavior is not documented. This is true for RPi OS, but may not be true for all distros.

You apparently have two programs: program.py & what I'll call somethingelse.py. Your question doesn't seem to indicate what you tried to start somethingelse.py.

There are two (2) widely-used & supported methods for starting programs at boot: cron and systemd. cron is simpler, systemd is more precise

I'd suggest you try cron first - nothing I see in your question would exclude it from consideration. Here's one way to do it:

Step 1: Since you are running your code as a background process, and starting from the command line, you could add a shebang to simplify things. As the first line in your script, add the following shebang:
#!/usr/bin/env python3

If you're using the older Python ver 2.x, replace python3 w/ python2

Step 2: Open your crontab & add an @reboot job:
$ crontab -e

Your crontab will open in your default editor. Once the editor has opened w/ your crontab, add this line:

@reboot /path/to/my/program.py >> /path/to/my/logfile.txt 2>&1

Save your crontab & exit the editor.

Step 3: Reboot your system to start program.py

And that's it. cron jobs run in the "background" because they aren't started from an interactive shell, and they're not attached to any terminal. Consequently, any textual output from your program will go to the "bit bucket". There are two redirects added above to save that output to a file to help you with troubleshooting (in the unlikely event you make a coding error). The >> redirect is the "append" form, which simply means that each output will be "appended" to the end of logfile.txt. The second redirect ( 2>&1 ) allows you to capture stderr errors as well as stdout.

1
  • Only works if you add the trailing ampersand, presumably since the script has an infinite loop.
    – Leon Segal
    Mar 14 at 9:21

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.