Ich stand heute vor dem Problem, dass ich mein Screensaver-Script nicht in den Autostart bekam: Egal ob per crontab oder rc.local – nach dem Bootup war das Python3-Script entweder nicht gestartet oder hat – aus welchen Gründen auch immer – 100% CPU-Last verbraten.
Also, per „apt-get install screen“ das Programm Screen ausgepackt, mit dem man virtuelle Konsolen-Sessions erzeugen kann, die auch bei ausgeloggtem SSH-Terminal bestehen bleiben und weiter laufen.
Das Problem: Meine Python3-Screen-Sitzung habe ich auch mit Screen nicht zum laufen gebracht; aus folgendem Grund: Wenn Screen in der crontab oder dem rc.local-Script eingetragen wird, muss man die Parameter „-m -d“ angeben, damit die Screen-Sitzung direkt „detached“ wird:
|
1 2 3 |
-d -m Start screen in "detached" mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts. |
Also, wer eine Screen-Sitzung per „crontab -e“ beim Systemstart mitladen möchte, der fügt folgende Zeile ein:
|
1 2 3 |
screen -m -d <befehl> # Beispiel: screen -m -d python3 /home/pi/screensaver.py |
Nach dem Bootvorgang kann man sich per Putty verbinden und mittels des Befehls
|
1 |
screen -ls |
die aktiven Sitzungen anzeigen lassen:
|
1 2 3 4 |
pi@raspi01 ~ $ screen -ls There is a screen on: 2102..raspi01 (15.01.2014 19:13:26) (Detached) 1 Socket in /var/run/screen/S-pi. |
Und mittels
|
1 2 3 |
screen -x <PID> # Beispiel: screen -x 2102 |
Öffnet man die in den Hintergrund geschickte Sitzung. Um Sie zu beenden, kille ich meistens einfach die PID:
|
1 |
kill 2102 |
… [Trackback]
[…] Informations on that Topic: 3bm.de/2014/01/15/debian-script-per-screen-beim-systemstart-per-crontab-ausfuehren/ […]