[Raspbian] systemd beendet Programm im Hintergrund

jusaca

Commander
Registriert
Apr. 2008
Beiträge
2.230
Ich habe bisher nicht viel Erfahrung mit Linux und habe mir jetzt einen Raspberry Pi 3 mit Raspbian aufgesetzt, um ein wenig zu experimentieren.
Dazu habe ich mir in C ein kleinen Programm geschrieben, dass ich über SSH aufrufe und das dann im Hintergrund über OneWire-Kommunikation einen Temperatursensor auslesen und die Werte mitloggen soll. Das klappt soweit auch ganz gut, allerdings läuft das Programm immer nur für so etwa 4 bis 5 Stunden und wird dann beendet - und ich konnte den Fehler bisher einfach nicht finden!

Mit journalctl habe ich zum jeweiligen Zeitpunkt des Log-Endes die Meldungen gefunden, dass systemd eine session beendet hat. Da dies jedes Mal mit dem letzten Zeitstempel im Logfile übereinstimmt, gehe ich mal stark davon aus, dass es sich bei der session um mein Programm handelt.

Die Meldung lautet jedes Mal:
Code:
systemd[1]: session-c15.scope: Succeeded.
systemd-logind[357]: Removed session c15.
systemd[1]: Stopping User Manager for UID 1000...
Die session Nr ist immer abweichend.

Gibt es eine Möglichkeit, wie ich mehr Informationen bekommen kann? Gibt es noch einen Log wo gepseichert wird, aus welchem Grund die session beendet wurde? Oder gibt der oben gepostete Log Informationen, die ich einfach nicht erkenne/verstehe?

Viele Grüße
jusaca
 

Anhänge

  • journalctl.PNG
    journalctl.PNG
    91,4 KB · Aufrufe: 262
jusaca schrieb:
dass ich über SSH aufrufe und das dann im Hintergrund

Zur Fehlersuche sollte vielleicht angegeben werden was du genau gemacht hast wenn der Fehler dann aufgetreten ist.

Für "im Hintergrund laufen" gibt es bei Linux verschiedene Möglichkeiten.
screen und tmux sind zB recht verbreitet um eine Session und damit ein Programm offen zu halten. Screen bietet logging via -L. Damit ist dann ein beliebiges Programm im Vordergrund in einer tmux/screen session und die Ausgabe ist archiviert.

Ein Anwendungsbeispiel: Man meldet sich an seinem Server mittels SSH an und startet ein Programm. Beendet man nun die SSH-Sitzung, wird auch das Programm beendet. Mit screen kann man dies verhindern
aus dem verlinkten screen Eintrag

Ansonsten kann journalctl doch die Programme anzeigen (man journalctl -> -u Option zum Beispiel), wenn systemd units als Hintergrunddienst eingerichtet sind / der Prozess ein echter Daemon ist.
 
Das ist erst mal soweit klar, wenn du ein Programm über eine SSH Sitzung startest und diese SSH Sitzung beendet wird, fliegt das Programm mit weg.

Du kannst entweder das Programm mit dem Befehl "nohup temperaturprogramm" starten, oder halt es gleich richtig machen und dir einen Dienst bauen, der dann automatisch beim hochfahren des Systems gestartet wird.

Mit systemd ist das ja relativ einfach, dir eine solche Konfiguration zu erstellen. Im folgenden Beispiel, eine einfache Variante. Das Programm wird gestartet, nachdem Netzwerk Dienste da sind und zudem automatisch wieder gestartet, wenn sich das Programm warum auch immer irgendwie abschießt.

Natürlich musst du diese Unit File manuell anlegen und dann auch systemd noch mitteilen, dass es auch beim Systemstart dem Kram ausführt.

Der Einfachheit halber auch nur eine mögliche Variante:
1. Das File im Ordner /etc/systemd/system mit einem gescheiten Namen mit der Endung service erstellen, z.B. temperaturprogramm.service
2. Mit dem Kommando "systemctl enable temperaturprogramm.service" systemd dazu veranlassen beim Start das Unit File zu verarbeiten
3. Manuell kann man dann den Service mit "systemctl start temperaturprogramm.service" auch direkt starten

Bash:
[Unit]
Description=Beschreibung
After=network.target

[Service]
ExecStart=Programmpfad
Restart=always

[Install]
WantedBy=multi-user.target
 
  • Gefällt mir
Reaktionen: Raijin und lokon
Oh, das habe ich vergessen zu erwähnen: Ich habe das programm über SSH mit "nohup" gestartet und die SSH Verbindung dann beendet. Das Programm ist dann auch problemlos weiter gelaufen, und dann eben erst nach einigen Stunden abgestürzt. Auch im nohup.out wurde keine Absturzmeldung geschrieben.

Danke für die Infos zum automatischen Start, das werde ich später sicher so einrichten. Momentan würde ich es gerne erstmal alles Terminalgesteuert zum Laufen bekommen.
 
Das Ding über systemd zu starten, würde dein Problem auf jeden Fall lösen. Ich vermute mal, dass auch der Mutterprozess nohup gekillt wird, sobald der User abgemeldet wird. Ich meine mich erinnern zu können, dass bei einem Logout der systemd alle mit dem User verbundenen Prozesse mit killt.

Ggf. wäre die Lösung, beim Kommando ein & an das Ende anzuhängen. Also "nohup befehl &", oder aber das Verhalten vom systemd zu ändern. Schau mal ob in der Konfigurationsdatei /etc/systemd/logind.conf
KillUserProcesses=yes konfiguriert ist, wenn ja könnte ein KillUserProcesses=no helfen.

Ich würde es aber einfach gleich richtig machen, statt herum zu frickeln ;)
 
Rache Klos schrieb:
Ich würde es aber einfach gleich richtig machen, statt herum zu frickeln ;)
Ganz genau. Es ist sinnfrei, auf Krampf zu versuchen es auf die falsche Weise zum Laufen zu bringen, um es kurz danach binnen weniger Sekunden richtig zu machen.
 
Der Plan ist halt nicht, dass das Programm von alleine beim Booten startet. Ich würde gerne den Programmstart von Hand triggern. Und wie gesagt, beim Ausloggen aus der SSH Verbindung bricht die Ausfühung ja nicht ab, sondern erst Stunden später.

Aus welchem Grund ist denn ein manueller Programmstart so gefrickelt?
 
Dann legst du halt nur das Unit File an und lässt den Befehl "systemctl enable temperaturprogramm.service" weg, dann kannst du das Programm manuell über "systemctl start temperaturprogramm.service" starten und mit "systemctl stop temperaturprogramm.service" stoppen. Vorteil ist dann aber auf jeden Fall, dass die Ausgaben vom Programm via journalctl eingesehen werden können.

Die SSH Sitzung und der User Logon sind zwei verschiedene paar Schuhe, durch nohup verhinderst du zwar das Beenden wenn das Terminal zugemacht wird, aber nicht wenn die User Session irgendwann später gekillt wird.

Die anderen Lösungsansätze habe ich dir ja auch mitgeteilt, letztendlich weißt aber nur du, warum du das Programm manuell starten möchtest.
 
Ah! Ich glaube jetzt habe ich es verstanden! Danke, dann wird das gleich mal so getestet =)
 
Zurück
Oben