Erzeugung log-Datei durch service

wonk · June 7, 2025 at 11:22 AM New

Hallo,

ich habe ein Python3-Prog , das wahlweise zu debugging-Zwecken eine log-Datei erzeugt mit print (..., file=log). Beim Start im Terminal funktioniert das problemlos. Es soll aber letztlich als service laufen, dann funktioniert es nicht mehr. Ich habe es schon mit StandardOutput= null und StandardOutput=file:<Pfad> versucht, der serivice erzeugt nichts.

Der service läuft mit user=pi, das python-Prog und die log-Datei hat den gleichen owner, auch Schreibrechte auf die log-datei sind vorhanden. Woran kann es liegen?

Bot · Vor 5 Minuten

Erzeugung log-Datei durch service? Schau mal ob du hier fündig wirst!

noisefloor · June 7, 2025 at 11:38 AM New

Hallo,

grundsätzlich: für's Logging gibt es das Python logging Modul, das standardmäßig an Board ist.

Was für ein Objekt ist `log` bei dir? Hat `log` eine `write` Methode? Sonst kann das sowieso nicht funktionieren. Wenn es aktuell nicht funktioniert solltest du im Journal von systemd eine Fehlermeldung finden.

Temporäres Schmalspurlogging kann man auch so machen, dass man einfach `print` Funktionen seinen Code einbaut, ohne `file=...` oder so. Wenn ein Python-Skript als Service Unit läuft, landen standardmäßig alle Ausgaben von `print` im zentralen Log von systemd, den du mit journalctl abfragen kannst. Aber, wie gesagt, richtiges Logging besser mit dem logging Modul implementieren.

Gruß, noisefloor

**hyle** · June 7, 2025 at 11:47 AM New

Man könnte auch das Arbeitsverzeichnis angeben, in dem das Skript läuft:

Code

[Service]
WorkingDirectory=/Pfad/zum
ExecStart=/Pfad/zum/Skript.py

Bot · Vor einem Moment

wonk · June 7, 2025 at 3:08 PM New

Hallo!

Danke es läuft jetzt!

noisefloor · June 8, 2025 at 9:16 AM New

Quote from wonk

Danke es läuft jetzt!

Das ist gut. Um den Leute zu helfen, die vielleicht irgendwann mal das gleiche Problem haben, wäre es auch sehr schön, wenn du schreiben würdest, was du geändert hast, damit es funktioniert. "Es läuft jetzt" ohne Kontext ist ansonsten für die Nachwelt ziemlich nutzlos.

Gruß, noisefloor

wonk · June 10, 2025 at 10:04 AM New

Hallo,

würde ich im Prinzip gern. Aber leider geht es mir als Linux-dummy öfters so, dass ich alles mögliche gegoogelte (oder aus dem Forum) probiere, bis es funktioniert. Dann weiß ich nicht mehr, was letztlich der entscheidende Schritt war, und es kann auch sein, dass ich zuvor irgendwann die richtige Lösung schon hatte, aber wegen eines anderen elementaren Fehlers übersehen hatte. Es ist dann selbst nachträglich schwierig, den eigentlichen Fehler zu finden.

Ich weiß, spricht nicht gerade für eine systematische Arbeitsweise. Aber leider ist der Weg über ein systematisches Verständnis aller relevanten Linux-Arbeitsweisen zu weit für mich, vermutlich auch für viele andere.

Deswegen auch nochmals danke für die Unterstützung

Bot · Vor einem Moment

noisefloor · June 10, 2025 at 10:59 AM New

Wie du dahin gekommen bist ist am Ende uns egal. Das Ergebnis zählt. Und das Ergebnis ist die systemd Service Unit, die bei dir funktioniert. Und _die_ kannst du hier posten.

Gruß, noisefloor

wonk · June 13, 2025 at 10:28 AM New

Hallo,

kann ich gern machen:

[Unit]
Description=sperre.py
After=syslog.target network.target ntp.service rc-local.service

[Service]
Type=simple
User=pi
WorkingDirectory= /home/pi/
ExecStart=/home/pi/sperre.py
StandardOutput=file:/home/pi/sperre.log
#StandardOutput=null

[Install]
WantedBy=multi-user.target

Aber es kommt sicherlich zusätzlich auf den owner und die Rechte an den Dateien an:

*.service: owner root, lesbar

*.py: owner pi, lesbar, ausführbar

*.log: owner pi. lesbar schreibbar, ausführbar

rpi444 · June 13, 2025 at 10:54 AM New

Quote from wonk

Aber es kommt sicherlich zusätzlich ...

BTW: Siehe z. B. für deinen Fall, auch bzgl. " user-unit vs. User=<user>".

Bot · Vor einem Moment

**hyle** · June 13, 2025 at 2:24 PM New

Quote from wonk

*.log: owner pi. lesbar schreibbar, ausführbar

Wozu?

**hyle** · June 13, 2025 at 3:17 PM New

Aus Neugier habe ich das Ganze jetzt mal nachvollzogen und richtig geraten. Meine Vermutung war das alte Leid der fehlenden Pfade und deshalb hatte ich die Angabe von WorkingDirectory= vorgeschlagen. Mein Testumfeld ist ein einfaches Python-Skript:

Python: logdatei_per_print.py

#!/usr/bin/env python3

from pathlib import Path

SELF_PATH = Path(__file__).parent
LOGFILE = SELF_PATH / "log.txt"
#LOGFILE = "log.txt"

def main():
    with open(LOGFILE, 'a') as log:
        log.write('Test \n')

if __name__ == "__main__":
    main()

Display More

Die abschließende Service Unit ist auch einfach:

Code: logfiletest.service

[Unit]
Description=logdatei_per_print
After=network.target

[Service]
Type=simple
User=hyle
ExecStart=/home/hyle/skripte/logdatei_per_print.py

[Install]
WantedBy=multi-user.target

Display More

Getestet habe ich nur durch Starten der Unit mit sudo systemctl start logfiletest.service , also kein Autostart enabled usw.

Also... Wenn im Skript die Zeile 6 aktiv ist (so wie aktuell oben), dann startet die Service Unit so wie sie ist das Skript und erzeugt die Logdatei.

Ist die Zeile 7 aktiv, dann passiert nichts dergleichen. Dann hilft allerdings WorkingDirectory=/home/hyle/skripte in der Service Unit. Damit wird die Logdatei wieder erstellt.

Martin28 · June 13, 2025 at 5:01 PM New

Wenn ich in der log.service den User= weglasse, schreibt systemd bei mir ins Wurzelverzeichnis '/'. Nur wenn ich einen User= verwendet, der dort keine Schreibrechte hat, wird keine Log-Datei erstellt. Das Problem sollte man auch im Journal angezeigt bekommen: bei mir log.txt: Keine Berechtigung

Aber generell gilt natürlich immer: absolute Pfade oder ein explizites Arbeitsverzeichnis mit angeben. Und auf die Berechtigungen achten.

Gruß Martin

meine Test-Unit:

Bash

# systemctl cat log
# /etc/systemd/system/log.service
[Unit]
Description=Log - Test

[Service]
#User=alarm
#ExecStart=/home/alarm/bin/log.py
ExecStart=/usr/bin/bash -c 'while true; do echo Hallo >> log.txt; sleep 5; done'

Bot · Vor einem Moment

Participate now!