Z niekończącą się pętlą w skrypcie wydaje się, że powinien on działać w tle bez końca jako usługa. Uruchamianie usług w dzisiejszych czasach odbywa się za pomocą systemd przy użyciu plików jednostek. Po prostu utwórz nową usługę za pomocą:

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

W pustym edytorze wstaw te instrukcje , zapisz je i zamknij edytor:

  [Unit] Description = Mój skrypt do monitorowania przycisku zamykaniaAfter = multi-user.target [Service] ExecStart = / usr / bin / python3 / home / pi / Documents / script.py [Install] WantedBy = multi-user.target  

Włącz i monitoruj usługę za pomocą:

  rpi ~ $ sudo systemctl enable --now myscript.servicerpi ~ $ systemctl status myscript.service  

Dane wyjściowe instrukcji print () znajdziesz w dzienniku:

  rpi ~ $ journalctl -b -e  

Powinieneś utworzyć skrypt bash, który uruchamia skrypt Pythona, taki jak:

  #! / bin / bashsudo python3 /path/to/python/file.py

upewnij się, że jest wykonywany za pomocą chmod + x po utworzeniu skryptu umieść plik bash w

/etc/init.d/ 

a następnie ustawić automatyczne uruchamianie

  sudo update-rc.d celeryd defaultssudo update-rc.d celeryd enable  

to jest to

Plik skryptu

1. Utwórz plik skryptu bash do uruchamiania kodu:

  nano / etc / systemd / system / test .sh  

Poza tym nie jest ważne, gdzie utworzysz plik i jaką nazwę ustawisz.

2. Dodaj poniższy wiersz do ten plik skryptu:

  #! / bin / bashsleep 5 && python3 /home/pi/Documents/script.py; 

Ustawiłem 5-sekundowy tryb uśpienia, ponieważ pomijam każdy błąd, który pojawia się, jeśli natychmiast uruchomisz plik Pythona.

Crontab

1. Otwórz tabelę crontab przez:

  crontab -e  

Jeśli vi przeszkadza Ci edytor, możesz otworzyć tabelę crontab przez:

  export VISUAL = nano; crontab -e 

2. Następnie dodaj tę linię na końcu pliku:

  @reboot bash / etc / systemd / system / his-chat-client.sh  

Opcjonalnie

Jeśli chcesz sprawdzić dziennik kodu, zmień plik skryptu na :

  #! / bin / bashsleep 5 && python3 /home/pi/Documents/script.py | & tee -a /var/log/test.log;

Możesz usunąć dziennik co tydzień, jeśli obawiasz się o pojemność karty SD. Po prostu dodaj tę linię na końcu crontab:

  5 8 * * 5 > /var/log/test.log  

Plik test.log będzie opróżniany w każdy piątek o 08:05.

Przede wszystkim spróbuj zrozumieć, co jest nie tak. Co możesz zrobić:

• zaloguj wyniki zadań cron do pliku dziennika lub:
• uruchom skrypt w sesji ekranowej GNU i zaloguj się do wyjścia konsoli do plik
• , a także najbardziej oczywiste, dodaj do kodu obsługę wyjątków , rejestruj błędy w pliku, abyś mógł je zbadać. Gdybyś miał obsługę wyjątków, prawdopodobnie miałbyś już pewne wskazówki dotyczące tego, co się dzieje.

W tym przypadku najbardziej prawdopodobnym powodem jest to, że cron nie ma kodu PATH . Jest to bardzo częsty problem z zadaniami cron. Ustaw PATH w swojej tabeli crontab lub dodaj pełną ścieżkę do python3 na Raspberry PI, która powinna be: / usr / bin / python3 (możesz uruchomić który python3 ma sprawdzić). Więc twoja linia crona powinna wyglądać tak:

  / usr / bin / python3 /home/pi/Documents/script.py

Jest to również możliwe że twój skrypt zależy od pewnych usług, które nie są jeszcze załadowane w momencie wywołania skryptu. Jest to częsta pułapka podczas uruchamiania skryptów startowych: wiele skryptów zakłada na przykład, że sieć będzie gotowa, ale działa zbyt wcześnie.

Co możesz zrobić: napisz własną usługę Systemd dla swojego skryptu ( przykład). Następnie określasz, że twoja usługa zależy od innej usługi i nie powinna być uruchamiana, dopóki wszystkie zależności nie zostaną spełnione.

Domyślam się, że masz do czynienia z fizycznymi przyciskami, które wyzwalają akcje (przepraszam, nie znam ze wszystkimi tymi modułami). Wydaje mi się, że usługa taka jak triggerhappy może ładnie zaspokoić Twoje potrzeby (chociaż do tej pory nie korzystałem z niej z GPIO). Jest dostępny jako standardowy pakiet w dystrybucjach Linuksa.

Będzie to działać pod cron , jeśli będziesz pamiętać o ograniczeniach crona. Możesz spróbować tego:

  crontab -e # w edytorze, dodaj następujący wiersz do swojej tabeli crontab: @reboot (/ bin / sleep 30; / usr / bin / python3 /home/pi/Documents/script.py >> / home / pi / cronjoblog 2>&1)  

Podsumowanie wpisu crontab :

• 30 sekund uśpienia kończy się przed próbą uruchomienia skryptu przez cron . To przezwycięża jedno z ograniczeń cron . Zwróć uwagę, że 30 sekund może oznaczać więcej uśpienia niż to wymagane (lub mniej, ale to wątpliwe), więc możesz spróbować skrócić ten czas, jeśli czekanie 30 sekund jest niewygodne.

• Kompletne specyfikacje plików dla wszystkiego to przesada, ale najlepiej jest zachować szczególną ostrożność, dopóki nie dowiesz się, jakie jest środowisko cron .

• każde wyjście stderr z twojego skryptu jest przekierowywane do pliku dziennika w / home / pi / cronjoblog ; pomoże ci to, jeśli wymagane jest dalsze debugowanie.