Diese Seite zeigt das Format einer Praxisnotiz. Die Befehle lesen Status und Konfiguration. Sie wurden hier nicht auf deinem Server ausgeführt. Ersetze mein-dienst.service durch den tatsächlichen Dienstnamen.

Der gleiche Rechner.
Eine andere Umgebung.

Im Terminal hast du vielleicht das virtuelle Python Environment aktiviert und bist im richtigen Verzeichnis. systemd übernimmt diese Shell Umgebung nicht automatisch. Entscheidend ist, welcher Benutzer den Dienst startet, welcher Interpreter verwendet wird und welche Einstellungen die Unit tatsächlich enthält.

Das erklärt noch nicht jeden Fehler. Aber es gibt der Suche eine Richtung.

Erst schauen, was wirklich passiert.

Der Status zeigt den aktuellen Zustand und einen Ausschnitt der letzten Meldungen:

systemctl status mein-dienst.service --no-pager --full

Für die letzten 80 Protokolleinträge:

journalctl -u mein-dienst.service -n 80 --no-pager

Falls deine Berechtigungen nicht ausreichen, ist ein entsprechend berechtigter Benutzer nötig. Suche nach der konkreten Fehlermeldung, beispielsweise einem fehlenden Modul, einer nicht gefundenen Datei oder verweigertem Zugriff.

«Failed» ist der Zustand. Die Ursache steht meistens weiter unten.

Vier Unterschiede, die sich zu prüfen lohnen.

1. Was ist überhaupt konfiguriert?

systemctl cat mein-dienst.service

Damit siehst du die Unit Dateien und vorhandene Ergänzungen. Prüfe besonders User=, ExecStart=, WorkingDirectory= und allfällige EnvironmentFile= Angaben.

2. Welches Python wird gestartet?

Wenn deine Anwendung ein virtuelles Environment verwendet, sollte der Startbefehl auf den dafür vorgesehenen Interpreter oder Programmstarter zeigen. Ein python aus deiner interaktiven Shell ist nicht automatisch derselbe Interpreter wie beim Dienst.

3. Wo beginnt die Anwendung?

Relative Dateipfade beziehen sich auf das Arbeitsverzeichnis. Ohne passende Einstellung kann die Anwendung ihre Konfiguration oder Daten an einer anderen Stelle suchen als bei deinem manuellen Start.

4. Was darf der Dienstbenutzer?

Der konfigurierte Benutzer braucht Zugriff auf die benötigten Dateien und Verzeichnisse. Zusätzliche Schutzoptionen der Unit können Zugriffe weiter begrenzen. Den Dienst deshalb einfach als root laufen zu lassen, löst die Ursache nicht sauber.

Konfigurationsausgaben können sensible Angaben enthalten. Vor dem Weitergeben Passwörter, Schlüssel und interne Informationen entfernen.

Eine Änderung.
Dann wieder nachschauen.

Wenn du einen Unterschied gefunden hast, ändere gezielt diese eine Einstellung. Ob ein Neuladen der Unit Definition und ein Neustart nötig sind, hängt von der Änderung ab. Ein Neustart kann laufende Anfragen unterbrechen. Plane ihn passend zum Betrieb.

Danach wieder Status und Protokoll prüfen. Nicht gleichzeitig Python aktualisieren, Dateirechte umbauen und die ganze Unit ersetzen. Sonst läuft es irgendwann und niemand weiss weshalb.

Erst die Fehlermeldung lesen. Dann die Umgebung vergleichen. Der Server braucht dafür keinen Motivationsvortrag.

Zum Nachlesen

Zurück zu Linuxtec