Programmaufruf in Service-Unit funktioniert nicht

maksimilian · November 27, 2024 at 9:09 PM New

Hallo Ihr,

ich möchte den Aufruf eines Programms automatisieren und habe dafür eine System- und Timer-Unit eingerichtet. Der Aufruf des Programms im Terminal funktioniert aber in der Service-Unit nach Aufruf durch die Timer-Unit nicht.

Code

pi@raspitest:/etc/systemd/system $ sudo journalctl|grep winsol
Nov 27 20:44:16 raspitest systemd[1]: Starting getlog-winsol.service - Logdaten vom CMI holen...
Nov 27 20:44:17 raspitest systemd[1]: getlog-winsol.service: Main process exited, code=exited, status=255/EXCEPTION
Nov 27 20:44:17 raspitest systemd[1]: getlog-winsol.service: Failed with result 'exit-code'.
Nov 27 20:44:17 raspitest systemd[1]: Failed to start getlog-winsol.service - Logdaten vom CMI holen.

Service-Unit getlog-winsol.service:

Bash

#!/bin/bash
[Unit]
Description=Logdaten vom CMI holen
Wants=getlog-winsol.timer
[Service]
Type=oneshot
ExecStart=/usr/share/Technische-Alternative/Winsol/Winsol --console -a
[Install]
WantedBy=multi-user.target

Timer-Unit getlog-winsol.timer:

Bash

#!/bin/bash
[Unit]
Description=Logdaten vom CMI holen
Requires=getlog-winsol.service
[Timer]
Unit=getlog-winsol.service
OnCalendar=*-*-* 20:44:00
[Install]
WantedBy=multi-user.target

Code

pi@raspitest:/etc/systemd/system $ ls -l getlog-winsol*
-rw-r--r-- 1 root root 211 27. Nov 20:42 getlog-winsol.service
-rw-r--r-- 1 root root 183 27. Nov 20:43 getlog-winsol.timer

Code

pi@raspitest:/etc/systemd/system $ /usr/share/Technische-Alternative/Winsol/Winsol --console -a
pi@raspitest:/etc/systemd/system $

Code

pi@raspitest:/usr/share/Technische-Alternative/Winsol $ ls -l
insgesamt 8116
drwxr-xr-x 10 root root    4096 26. Nov 21:29 res
-rwxr-xr-x  1 root root 8304324 12. Okt 2023  Winsol
pi@raspitest:/usr/share/Technische-Alternative/Winsol $

Bot · Vor 5 Minuten

Programmaufruf in Service-Unit funktioniert nicht? Schau mal ob du hier fündig wirst!

simonz · November 27, 2024 at 9:18 PM New

Zumindest mal die Shebang Zeile in den beiden Unit-Dateien gehört dort nicht hin:

Quote from maksimilian

#!/bin/bash

framp · November 27, 2024 at 9:36 PM New

Was liefert sudo journalctl -u getlog-winsol.service ?

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

rpi444 · November 27, 2024 at 10:29 PM New

Quote from maksimilian

Der Aufruf des Programms im Terminal funktioniert aber in der Service-Unit nach Aufruf durch die Timer-Unit nicht.

BTW: Deine service-unit und timer-unit sind nicht optimiert.

Funktionert es wenn Du die service-unit manuell ausführst?

framp · November 27, 2024 at 10:38 PM New

Quote from rpi444

Funktionert es wenn Du die service-unit manuell ausführst?

Interessant zu wissen das das geht. Wie

rpi444 · November 27, 2024 at 10:46 PM New

Quote from framp

Wie

Z. B.:

Code

sudo systemctl start getlog-winsol.service

systemctl status getlog-winsol.service
systemctl is-enabled getlog-winsol.service  # was es nicht sein sollte wenn eine timer-unit benutzt wird
systemctl is-active getlog-winsol.service

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

framp · November 27, 2024 at 10:54 PM New

Ok. Danke. Ich dachte es gibt eine Moeglichkeit realtime den Service zu starten und zu monitoren.

So startest Du ihn, fragst den Status ab ob enabled und active. Final fragst Du das Log ab mit journalctl -u getlog-winsol.service

Das funktioniert perfekt. Ich dachte nur es gaebe da eine einfachere Moeglichkeit die ich noch nicht kenne.

rpi444 · November 27, 2024 at 11:05 PM New

Quote from framp

Ich dachte es gibt eine Moeglichkeit realtime den Service zu starten und zu monitoren.

Was genau meinst Du mit "realtime" starten?
Der TE will die service-unit zu einer bestimmten Tageszeit (OnCalendar), via timer-unit starten.

Code

:~$ systemd-analyze calendar "*-*-* 20:44:00"
Normalized form: *-*-* 20:44:00
    Next elapse: Thu 2024-11-28 20:44:00 CET
       (in UTC): Thu 2024-11-28 19:44:00 UTC
       From now: 21h left

Monitoren wäre möglich, z. B. durch erstellen einer leeren Datei oder mit einem Eintrag (Uhrzeit) in eine LogDatei oder gleichwertig.

framp · November 27, 2024 at 11:19 PM New

Quote from rpi444

Was genau meinst Du mit "realtime" starten?

Starten und auf de Konsole die Ausgaben sehen. Aber mir wird eben klar dass das bei einer Timerunit nicht geht. Die Ausgaben einer Serviceunit kann man mit journalctl nach dem Start beobachten wie Du geschrieben hast.

D.h. man testet erst einmal die Serviceunit manuell und wenn die funktioniert muss man auf die Timerunit warten. Zum Testen kann man die doch auch mal auf alle 3 Minuten setzen und dann per journalctl checken.

Ich bin immer noch dabei mich mit systemd vertraut zu machen - also sorry wenn ich was falsch verstanden habe ...

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

rpi444 · November 27, 2024 at 11:25 PM New

Quote from framp

Starten und auf de Konsole die Ausgaben sehen. Aber mir wird eben klar dass das bei einer Timerunit nicht geht.

Das geht auch mit der timer-unit (... wenn man will bzw. wenn man es zum testen/debuggen haben muss). Denn die timer-unit startet die service-unit und die service-unit führt das "Script" aus, mit dem die gewünschte Ausgabe produziert werden kann.

noisefloor · November 28, 2024 at 9:57 AM New

Hallo,

was macht denn genau der Aufruf Winsol --console -a ? Also was passiert, wenn du ihn in einem interaktivem Terminal ausführst?

Gruß, noisefloor

peuler · November 28, 2024 at 9:58 AM New

Diese Punkte sind mir aufgefallen:

1) In der Service-Unit getlog-winsol.service sorgt die Zeile Wants=getlog-winsol.timer dafür, dass die Timer-Unit getlog-winsol.timer aufgerufen wird, sobald getlog-winsol.service gestartet wird. Das ist nicht zielführend, da ja gerade die Timer-Unit die Service-Unit starten soll. Daher ist diese Zeile zu löschen.

2) In der Service-Unit getlog-winsol.service würde ich den Type von oneshot auf simple ändern. Nur wenn es zwingend erforderlich ist, oneshot zu haben, dann würde ich das setzen.

3) In der Timer-Unit getlog-winsol.timer hast Du angegeben Requires=getlog-winsol.service Das ist m.E. ein Widerspruch in sich, da die Timer-Unit die Service-Unit aufrufen soll. Mit Requires=getlog-winsol.service teilst Du aber der Timer-Unit mit, dass zwingend die Service-Unit gestartet werden muss, damit die Timer-Unit gestartet werden kann. Und das ist unlogisch, da die Timer-Unit die Service-Unit starten soll. Oder anders ausgedrückt: Systemd führt die Timer-Unit aus und diese wiederum sorgt dafür, dass von Systemd die Service-Unit gestartet wird. Daher ist die erwähnte Zeile zu löschen.

4) Systemd-Units werden unter dem User root gestartet. Es gibt Programme, die das unterbinden. Daher würde ich noch testen, ob das erwähnte Programm als User root sich starten lässt (=Einloggen mit Benutzerkennung root). Beachte, dass es einen Unterschied gibt, ob ich als User root eingeloggt bin oder mit root-Berechtigung arbeite.

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

rpi444 · November 28, 2024 at 11:42 AM New

Quote from maksimilian

Der Aufruf des Programms im Terminal funktioniert ...

Hast Du den Aufruf des Programms im Terminal, als root oder als normaler user gemacht?

maksimilian · November 28, 2024 at 6:53 PM New

Danke für die rege Anteilnahme Schon mal vorweg: den Inhalt der Units habe ich von einer anderen Logging-Funktion übernommen (natürlich mit geändertem Programmnamen); und die funktioniert in einem anderen Bookworm. Gut, die Ranbedingungen können natürlich bei beiden Installationen unterschiedlich sein. Die Startzeile in den Units mit #!/bin/bash sollte vom Init-System nur als Kommentar interpretiert werden. Warum das bei mir drinsteht, weiß ich nicht mehr.

Nähere Erläuterunge zum Programm Winsol (ein Produkt der Technischen Alternative) sollten hier nicht notwendig sein und machen den Thread nur unübersichtlicher.

Interessant jetzt: Der Aufruf im Terminal von

Code

/usr/share/Technische-Alternative/Winsol/Winsol --console -a

funktioniert als Administrator nicht, und es wird keine Fehlermeldung ausgegeben! Natürlich gibt es bei explizitem Aufruf keinen Eintrag im Journal. Bisher hatte ich zum Testen den Aufruf unter dem Benutzer pi erfolgreich ausgeführt und nahm an, dass er es unter root erst recht tun würde.

Ich teste mal weiter.

KKoPi · November 28, 2024 at 7:19 PM New

Falls Du nicht herauskriegst, warum es nicht als root funktioniert, kannst Du die Unit ggf. auf einen anderen User zwingen, im Abschnitt [Service]

systemd.exec

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

rpi444 · November 28, 2024 at 8:04 PM New

Quote from KKoPi

..., kannst Du die Unit ggf. auf einen anderen User zwingen, im Abschnitt [Service]

Wenn das auch nicht funktioniert, dann als user-unit konzipieren bzw. benutzen. Z. B.:

Code

:~$ systemctl --user list-timers --all
NEXT LEFT LAST                        PASSED    UNIT              ACTIVATES          
-    -    Thu 2024-11-28 19:37:49 CET 25min ago vino-server.timer vino-server.service

1 timers listed.

Code

:~$ systemctl list-timers --all
NEXT                        LEFT          LAST                        PASSED     UNIT                         ACTIVATES                     
Thu 2024-11-28 20:31:22 CET 27min left    Thu 2024-11-28 19:37:15 CET 26min ago  anacron.timer                anacron.service
Thu 2024-11-28 22:49:11 CET 2h 45min left Thu 2024-11-28 10:46:25 CET 9h ago     apt-daily.timer              apt-daily.service
Fri 2024-11-29 00:00:00 CET 3h 56min left -                           -          dpkg-db-backup.timer         dpkg-db-backup.service
Fri 2024-11-29 00:00:00 CET 3h 56min left Thu 2024-11-28 08:30:21 CET 11h ago    logrotate.timer              logrotate.service
Fri 2024-11-29 06:36:28 CET 10h left      Thu 2024-11-28 09:11:32 CET 10h ago    apt-daily-upgrade.timer      apt-daily-upgrade.service
Fri 2024-11-29 11:09:05 CET 15h left      Thu 2024-11-28 12:38:41 CET 7h ago     man-db.timer                 man-db.service
Fri 2024-11-29 19:51:14 CET 23h left      Thu 2024-11-28 19:51:13 CET 12min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2024-12-01 03:10:04 CET 2 days left   Sun 2024-11-24 08:58:49 CET 4 days ago e2scrub_all.timer            e2scrub_all.service
Mon 2024-12-02 00:36:14 CET 3 days left   Mon 2024-11-25 09:12:27 CET 3 days ago fstrim.timer                 fstrim.service

9 timers listed.

Display More

noisefloor · November 28, 2024 at 8:13 PM New

Dann trag' mal in der [Service] Sektion die Zeile User=pi ein, deaktiviere und aktiviere die Unit (sicherheitshalber) und probier' dann nochmal.

Gruß, noisefloor

RTFM · November 28, 2024 at 8:13 PM New

Wenn root ein File nicht ändern kann, dann ist vermutlich das "sticky bit" gesetzt (wie in /tmp).

In

[Service]

User=pi

Würde den user pi das ExecStart= ausführen lassen.

Servus !

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

**hyle** · November 28, 2024 at 8:36 PM New

Quote from maksimilian

Nähere Erläuterunge zum Programm Winsol (ein Produkt der Technischen Alternative) sollten hier nicht notwendig sein und machen den Thread nur unübersichtlicher.

Naja, die Frage was beim Aufruf passieren soll ist schon wichtig! Soll etwas in einem Terminal angezeigt werden oder wird da "nur" etwas im Hintergrund erledigt, was keine Ausgabe hat?

maksimilian · November 28, 2024 at 9:28 PM New

Hast natürlich recht, hyle. Die Parameter --console -a dienen für den Autostart von Winsol. Ich möchte das Programm auf meinem NAS laufen lassen, um Daten meiner Heizungsanlage automatisch loggen zu lassen, wie ich es bereits mit Daten meiner Wärmepumpe (Steuerung ist die Luxtronik) mache. Diese Aufrufparameter werden so vom Anbieter des Programms (Technische Alternative) vorgeschrieben.

Programmaufruf in Service-Unit funktioniert nicht

Participate now!

Users Viewing This Thread