Gelöst! Shell Skript für systemd Überwachung

[NAB]

Moin Nastra,

das sieht aber eigentlich ziemlich gut aus.

Code: Alles auswählen

Mär 17 07:21:24 HomeKitServer sudo[1126]:     root : TTY=unknown ; PWD=/ ; USER=pi ; COMMAND=/usr/local/bin/benachrichtigung.sh homebridge-test.service 30

Hier meldet sich sudo und möchte als Benutzer pi das Script /usr/local/bin/benachrichtigung.sh starten. Mit den beiden Argumenten "homebridge-test.service" und "30". Das erste ist die Unit, die sich gerade verabschiedet hat und das zweite ist das Nachrichtenlimit.

Als nächstes meldet sich dann ntfy:

Code: Alles auswählen

Mär 17 07:21:25 HomeKitServer sh[1125]:   File "/usr/local/bin/ntfy", line 7, in <module>
Mär 17 07:21:25 HomeKitServer sh[1125]:     from ntfy.cli import main
Mär 17 07:21:25 HomeKitServer sh[1125]:   File "/usr/local/lib/python2.7/dist-packages/ntfy/cli.py", line 12, in <module>
Mär 17 07:21:25 HomeKitServer sh[1125]:     from .data import scripts
Mär 17 07:21:25 HomeKitServer sh[1125]:   File "/usr/local/lib/python2.7/dist-packages/ntfy/data.py", line 9, in <module>
Mär 17 07:21:25 HomeKitServer sh[1125]:     makedirs(ntfy_data_dir)
Mär 17 07:21:25 HomeKitServer sh[1125]:   File "/usr/lib/python2.7/os.py", line 150, in makedirs
Mär 17 07:21:25 HomeKitServer sh[1125]:     makedirs(head, mode)
Mär 17 07:21:25 HomeKitServer sh[1125]:   File "/usr/lib/python2.7/os.py", line 150, in makedirs
Mär 17 07:21:25 HomeKitServer sh[1125]:     makedirs(head, mode)
Mär 17 07:21:25 HomeKitServer sh[1125]:   File "/usr/lib/python2.7/os.py", line 157, in makedirs
Mär 17 07:21:25 HomeKitServer sh[1125]:     mkdir(name, mode)
Mär 17 07:21:25 HomeKitServer sh[1125]: OSError: [Errno 13] Permission denied: '/root/.local'

Das sieht so aus als ob ntfy auf /root/.local zugreifen will. Und das darf es als Benutzer "pi" natürlich nicht. Kannst du dir darauf einen Reim machen? Das hat ntfy doch sonst nicht gemacht, oder? Hast du irgendwas an ntfy geändert? Oder an den Berechtigungen für /root/.local ?

Andererseits sagst du:

und der ntfy Befehl im Skript funktioniert auch.

Woran machst du das fest? Mir sieht es so aus als ob eben der ntfy Befehl das Problem macht.

[Nastra]

Code: Alles auswählen

Das sieht so aus als ob ntfy auf /root/.local zugreifen will. Und das darf es als Benutzer "pi" natürlich nicht. Kannst du dir darauf einen Reim machen? Das hat ntfy doch sonst nicht gemacht, oder? Hast du irgendwas an ntfy geändert? Oder an den Berechtigungen für /root/.local ?

Ne habe nichts geändert, alles wie gehabt.

Wenn ich die Zeile ins Terminal so eingebe, bekomme ich sofort eine Nachricht:

Code: Alles auswählen

pi@HomeKitServer:~ $ /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS"

Aber ich glaube ich habe den Fehler gerade gefunden, in dem Skript was ich zurzeit nutze wird der Befehl auch mit sudo und deinem -u pi versendet. Weiß zwar nicht wofür das -u pi steht, habe aber den Befehl jetzt mal abgeändert in:

Code: Alles auswählen

sudo -u pi /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS"

jetzt funktioniert er über das Terminal auch. Werde es gleich mal in Kombi mit dem Skript testen wenn ich daheim bin und mich wieder melden.

[scientific]

Prinzipiell ist es in Skripten besser runuser statt su/sudo zu verwenden, wenn ein Skript als root läuft und unter einer anderen Benutzerkennung (in deinem Fall pi) ausgeführt werden soll.

su/sudo starten nämlich eine ganze pam-Session, was runuser nicht tut. Mit su im Skript kannst du dir seltsame Sideeffects holen, die runuser nicht verursacht.

Lg scientific

[NAB]

Ohhh ... ich ahne, was da schief läuft. Das "-E" im sudo-Aufruf sorgt dafür, dass alle Environment-Variablen übernommen werden, inklusive der von Systemd, die das Script braucht um herauszufinden, warum der Dienst sich beendet hat.

Ich befürchte, ntfy nutzt eine dieser von root stammenden Environment-Variablen und kommt dadurch auf die Idee, /root/.local benutzen zu wollen.

scientific, kann runuser da irgendwie helfen? So wie ich die man page verstehe, würde sich das gleiche Problem ergeben.

Nastra, ja, probier das mal aus. Ob es funktioniert hängt mMn davon ab, wie dein sudo konfiguriert ist. Das "-u pi" sorgt einfach nur dafür, dass der Befehl ntfy als Benutzer "pi" ausgeführt wird statt als "root".

[Nastra]

So, habe es jetzt getestet. Mit der Zeile funktioniert es und ich werde benachrichtigt.

Code: Alles auswählen

sudo -u pi /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS

Das ist die Meldung die mir in Telegram angezeigt wird, der exit-code 1 ist nur bei ausstieg mit FAILURE richtig? Ist es ggf. möglich das "FAILURE" mit in der Nachricht einzublenden?

Code: Alles auswählen

Dienst homebridge-hue.service ausgefallen mit exit-code 1

@NAB @scientific

Ist jetzt noch Handlungsbedarf bezüglich des runusers? Wenn ja was muss ich da genau machen?

[scientific]

su durch runuser ersetzen. Sollte 1:1 funktionieren.

Ja, ich würds tun!

Runuser wird aus den Quellen von su gebaut und ist speziell für diese Zwecke.

[NAB]

Nastra, ich versuche dir mal zu erklären, welches Problem ich mit der Geschichte habe. Kurz zusammengefasst läuft es hinaus auf: es ist dein System.

Diese Zeile:

Code: Alles auswählen

ExecStopPost=/bin/sh -c "/usr/bin/sudo -E -u pi /usr/local/bin/benachrichtigung.sh %n 1200"

wird von deiner homebridge Unit aufgerufen, wann immer sie sich beendet. Die homebridge Unit läuft als root (deine Vorgabe, scheint so zu gehören). Das "sudo -E -u pi" wechselt dann sicherheitshalber die Benutzerrechte runter zum Benutzer "pi". Wo kommt der Benutzer pi her und was darf er? Keine Ahnung, wieder deine Vorgabe. Nun wird sudo hier als root ausgeführt, und da root bekanntlich alles darf, wird der Benutzerwechsel zu "pi" klappen, unabhängig von deiner sudo-Konfiguration. Das -E sorgt dafür, dass wir die "geheimen Botschaften" mitnehmen, in denen Systemd versteckt, warum deine homebridge sich beendet hat. Aus welchen Gründen kann so eine homebridge sich eigentlich beenden? Keine Ahnung, es ist dein Dienst.

Mit den Rechten von "pi" wird dann benachrichtigung.sh %n 1200 aufgerufen. Im %n versteckt sich der Dateiname der Systemd-Unit, die sich gerade beendet hat. Diesen Dateinamen missbrauche ich später, um den Zeitstempel darin zu speichern, im home-Verzeichnis von "pi". Bisher habe ich von dir nur "vernünftige" Dateinamen gesehen, aber was mag passieren, wenn du komische Sonderzeichen oder Leerzeichen einbaust? Keine Ahnung, das ist wieder dein Hoheitsgebiet.

Und nun zum Script benachrichtigung.sh. Wie gesagt läuft es unter den Benutzerrechten von "pi" - und geht mal dezent davon aus, dass "pi" ein Home-Verzeichnis hat. Da es komische Dateinamen auf deiner Platte speichert, die es nicht vollständig unter Kontrolle hat, fand ich es sicherer, die Benutzerrechte auf "pi" zu beschränken - so kann es im Problemfall weniger Schaden anrichten. Außerdem versucht es aus den "geheimen Botschaften" von Systemd schlau zu werden. Genauer gesagt aus den Variablen $SERVICE_RESULT $EXIT_CODE und $EXIT_STATUS.
So geheim sind die auch gar nicht, die sind hier dokumentiert:
https://www.freedesktop.org/software/sy ... .exec.html
ziemlich weit unten unter "Environment variables in spawned processes".
Wenn du genau hinguckst, ist die Sache etwas tricky. $SERVICE_RESULT kann zig verschiedene Werte annehmen:
"success", "protocol", "timeout", "exit-code", "signal", "core-dump", "watchdog", "start-limit-hit", "resources"
Beachte, dass "FAILURE" hier gar nicht auftaucht. Um es noch komplizierter zu machen, kann die Bedeutung von $EXIT_STATUS schwanken mit dem Inhalt von $SERVICE_RESULT. Wie wertet man das nun in deinem Interesse aus? Keine Ahnung. Das Script macht es sich momentan einfach: alles andere als "success" wird als Fehler behandelt und du wirst benachrichtigt. Ist das nun in deinem Interesse? Weiß ich nicht. Mit welchem $SERVICE_RESULT können sich deine Dienste überhaupt beenden? Keine Ahnung.

Ganz am Ende des Scriptes wird es dann spannend:

Code: Alles auswählen

/usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS"

Das funktioniert so nicht, da wir durch das -E die Umgebungsvariablen von root übernommen haben. ntfy kommt dadurch durcheinander und versucht auf Dateien von root zuzgreifen, obwohl es unter den Berechtigungen von "pi" läuft. Die korrekte Methode wäre jetzt herauszufinden, welche Umgebungsvariable das ist und diese auf den richtigen Wert zu setzen. Stattdessen kommst du mit einem Hack: du schreibst "sudo -u pi" davor. Das ist so einfach wie elegant - "pi" ruft hier sudo im eigenen Namen auf und da das -E hier fehlt, setzt sudo die Umgebungsvariablen auf die richtigen Werte für "pi". Schwupp, schon klappt es mit ntfy. Hier ruft also "pi" per sudo die Benutzerrechte von "pi" auf. Das ist von hinten durch die Brust ins Auge ... aber es funktioniert.

Das Problem an der Geschichte ist, dass es nur funktioniert, wenn sudo geeignet konfiguriert ist. "pi" muss berechtigt sein, per sudo in eigenem Namen ntfy aufzurufen. Klingt bescheuert, aber wenn das "pi" nicht ausdrücklich erlaubt ist, dann verhindert sudo die Ausführung von ntfy. Ist das nun gut so oder schlecht? Weiß ich nicht ... es ist ja dein System.

Wie du siehst ... es gibt eine ganze Menge Punkte, die eigentlich du entscheiden und abwägen musst. Insbesondere, bevor du die Lösung auf eine Horde unbedarfter Apple-User loslässt

der exit-code 1 ist nur bei ausstieg mit FAILURE richtig? Ist es ggf. möglich das "FAILURE" mit in der Nachricht einzublenden?

Wie oben erläutert, es gibt kein "FAILURE", darum kann man es auch nicht "einblenden". Du kannst aber einfach FAILURE in die Nachricht reinschreiben, wenn dir das so besser gefällt.

[scientific]

Ich bleib dabei, auch wenn es mit OnFailure ein Problem von systemd gibt, mit meinen beiden einfachen Units hast du alles was du brauchst.

Wenn du mehr überwachen willst, würd ich ein Monitoring-System wie z. B. Zabbix installieren.

[scientific]

Zabbix kannst du auch im Docker-Container installieren, ist FOSS, bietet eine feine Weboberfläche und die Möglichkeit über Trogger und Actions Emails und andere Benachrichtigungen zu versenden, wenn Services nicht laufen oder ausgefallen sind, die Load zu hoch ist, der Plattenplatz oder RAM knapp wird.

Wenn du deine Systeme beim Leben beobachten willst, ist das eine gute Wahl.

Lg scientific

[Nastra]

Moin Moin,

@NAB Danke für die Ausführlich Antwort und Erklärung

Code: Alles auswählen

Das "sudo -E -u pi" wechselt dann sicherheitshalber die Benutzerrechte runter zum Benutzer "pi". Wo kommt der Benutzer pi her und was darf er? Keine Ahnung, wieder deine Vorgabe.

Der User pi ist der Standard User der durch die Raspberry Pi Foundation angelegt wird. Nutze diesen User so lange ich denen ihre Images nutze

Code: Alles auswählen

Aus welchen Gründen kann so eine homebridge sich eigentlich beenden?

Zum Beispiel wenn ein Gerät im Heimnetzwerk, ein Server von einem Hersteller der benötigt wird um mit der API zu kommunizieren nicht erreichbar ist oder das Homebridge Plugin schlecht programmiert ist. Fehler bleibt aber eigentlich immer FAILURE was es ja garnicht gibt..

Code: Alles auswählen

Bisher habe ich von dir nur "vernünftige" Dateinamen gesehen, aber was mag passieren, wenn du komische Sonderzeichen oder Leerzeichen einbaust? Keine Ahnung, das ist wieder dein Hoheitsgebiet.

Wird nicht vorkommen bei mir Ne Spass, die Namenskonventionen habe ich bisher auch so in der kurz Anleitung zum erstellen von mehreren Instanzen bei uns im Forum festgelegt. Wenn einer Abweicht und ein Smilie einbaut ist es sein Problem

Code: Alles auswählen

und geht mal dezent davon aus, dass "pi" ein Home-Verzeichnis hat

Völlig richtig

Code: Alles auswählen

Das Script macht es sich momentan einfach: alles andere als "success" wird als Fehler behandelt und du wirst benachrichtigt. Ist das nun in deinem Interesse? 

Eigentlich schon, nur das normale Beenden durch den User soll es nicht berücksichtigen. Da es hier etwas nervig wäre. Kann man das irgendwie ausschließen?

Code: Alles auswählen

Mit welchem $SERVICE_RESULT können sich deine Dienste überhaupt beenden?

Bin ich ganz ehrlich, habe noch nie drauf geachtet für mich war bisher nur die selbständige Fehlerhaftebeendung interessant bei dem wir bisher von FAILURE gesprochen haben. Ich prüfe das mal.

Edit: Es gibt einmal diesen beim manuellen beenden:

Code: Alles auswählen

Mär 20 07:07:04 HomeBridgeServer homebridge[18513]: [2018-3-20 07:07:04] Got SIGTERM, shutting down Homebridge...
Mär 20 07:07:04 HomeBridgeServer systemd[1]: homebridge-test.service: Main process exited, code=exited, status=143/n/a
Mär 20 07:07:04 HomeBridgeServer sudo[18646]:     root : TTY=unknown ; PWD=/ ; USER=pi ; COMMAND=/usr/local/bin/benachrichtigung.sh homebridge-test.service 30
Mär 20 07:07:04 HomeBridgeServer sudo[18646]: pam_unix(sudo:session): session opened for user pi by (uid=0)
Mär 20 07:07:04 HomeBridgeServer sudo[18653]:       pi : TTY=unknown ; PWD=/ ; USER=pi ; COMMAND=/usr/local/bin/ntfy -b telegram send Dienst homebridge-test.service ausgefallen mit exit-code 143
Mär 20 07:07:04 HomeBridgeServer sudo[18653]: pam_unix(sudo:session): session opened for user pi by (uid=0)
Mär 20 07:07:05 HomeBridgeServer systemd[1]: Stopped homebridge-test.service.
Mär 20 07:07:05 HomeBridgeServer systemd[1]: homebridge-test.service: Unit entered failed state.
Mär 20 07:07:05 HomeBridgeServer systemd[1]: homebridge-test.service: Failed with result 'exit-code'.

und diesen wenn ein Fehler aufgetreten ist:

Code: Alles auswählen

Mär 20 07:02:31 HomeBridgeServer systemd[1]: homebridge-test.service: Main process exited, code=exited, status=1/FAILURE
Mär 20 07:02:31 HomeBridgeServer sudo[17051]:     root : TTY=unknown ; PWD=/ ; USER=pi ; COMMAND=/usr/local/bin/benachrichtigung.sh homebridge-test.service 30
Mär 20 07:02:31 HomeBridgeServer sudo[17051]: pam_unix(sudo:session): session opened for user pi by (uid=0)
Mär 20 07:02:31 HomeBridgeServer sudo[17058]:       pi : TTY=unknown ; PWD=/ ; USER=pi ; COMMAND=/usr/local/bin/ntfy -b telegram send Dienst homebridge-test.service ausgefallen mit exit-code 1
Mär 20 07:02:31 HomeBridgeServer sudo[17058]: pam_unix(sudo:session): session opened for user pi by (uid=0)
Mär 20 07:02:33 HomeBridgeServer systemd[1]: homebridge-test.service: Unit entered failed state.
Mär 20 07:02:33 HomeBridgeServer systemd[1]: homebridge-test.service: Failed with result 'exit-code'.

Code: Alles auswählen

as Problem an der Geschichte ist, dass es nur funktioniert, wenn sudo geeignet konfiguriert ist. "pi" muss berechtigt sein, per sudo in eigenem Namen ntfy aufzurufen. Klingt bescheuert, aber wenn das "pi" nicht ausdrücklich erlaubt ist, dann verhindert sudo die Ausführung von ntfy. Ist das nun gut so oder schlecht? Weiß ich nicht ... es ist ja dein System.

Mhhh, da muss ich leider auch passen so gut kenne ich mich mit den Benutzerrechten leider nicht aus. Aber so wie es jetzt ist wird es die Standardeinstellung sein die von der Pi Foundation vorgegeben ist und die bei 99% der Nutzer zutrifft vermute ich mal.

Code: Alles auswählen

Wie du siehst ... es gibt eine ganze Menge Punkte, die eigentlich du entscheiden und abwägen musst. Insbesondere, bevor du die Lösung auf eine Horde unbedarfter Apple-User loslässt  :wink: 

Deswegen bin ich ja hier um mir Fachkundigen Rat zu holen

Code: Alles auswählen

Wie oben erläutert, es gibt kein "FAILURE", darum kann man es auch nicht "einblenden". Du kannst aber einfach FAILURE in die Nachricht reinschreiben, wenn dir das so besser gefällt.

Da hätte man auch selber drauf kommen können

@scientific

Code: Alles auswählen

Wenn du mehr überwachen willst, würd ich ein Monitoring-System wie z. B. Zabbix installieren.

Habe ich mir gestern mal angeschaut, sieht sehr mächtig aus. Würde bestimmt seinen Zweck erfüllen, aber ich denke das es für den unbedarften Apple User wie NAB so schön sagt dann doch zu kompliziert wäre und für die reine Benachrichtigung über den Ausfall einer Intsatnz und ggf. eines Errors zu overloaded wäre
Aber danke für den Tip!

Habe das mit dem runuser jetzt getestet, klappt leider nicht bekomme keine Ausgabe oder ich habe es falsch verstanden?

Code: Alles auswählen

runuser -u pi /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS"

und

Code: Alles auswählen

runuser /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS"

Danke euch beiden!

Lg Nastra

[scientific]

Bei mir kommt in einr Rootshell ausgeführt

Code: Alles auswählen

 runuser -u scientific -- /usr/local/bin/ntfy -b telegram send 'Bla'

die Nachricht 'Bla' in Telegram an.

Trenne den Befehl, den du ausfühten willst, vom runuser mit '--' ab. Alles was nach -- kommt interpretiert runuser (wie su auch!) als den auszuführenden Befehl.

Willst du wirklich nur bei fehlerhaftem Ausfall von Homebridge benachrichtigt werden?

Und hast du noch immer deine 23 systemd-Units, oder hast du schon eine instanziierende, mit der du deine 23 Homebridge-Services aufrufst?

Lg scientific

[breakthewall]

Diese Zeile:

Code: Alles auswählen

ExecStopPost=/bin/sh -c "/usr/bin/sudo -E -u pi /usr/local/bin/benachrichtigung.sh %n 1200"

wird von deiner homebridge Unit aufgerufen, wann immer sie sich beendet. Die homebridge Unit läuft als root (deine Vorgabe, scheint so zu gehören). Das "sudo -E -u pi" wechselt dann sicherheitshalber die Benutzerrechte runter zum Benutzer "pi".

Gerade wenn man bereits Systemd nutzt, und ein Systemd-Unit hat, dann kann man doch auch dynamische Nutzer generieren lassen. Alternativ kann man Systemdienste auch mittels Rootrechten starten, und hinterher die Rechte wieder automatisch gemäß "man systemd.exec" entziehen lassen. Zumal ein mittels Rootrechten gestarteter Prozess, die Privilegien eines Root nicht dauerhaft oder gar in vollem Umfang benötigt. Von daher ist das eine praktische Sache, die auch noch weitere Restriktionen ermöglicht.

[Nastra]

@scientific

habe ich gemacht, hier das Ergebnis. Irgendwie hat er noch was zu meckern.

Code: Alles auswählen

pi@HomeBridgeServer:~ $ runuser -u pi -- /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS"
runuser: may not be used by non-root users

Code: Alles auswählen

Willst du wirklich nur bei fehlerhaftem Ausfall von Homebridge benachrichtigt werden?

Ich bin ganz ehrlich, ich bin zwischen allen Lösungen momentan hin und hergerissen. Habe ja alle ausprobiert.

Mit der Skript Variante reporter.sh bin ich bis jetzt am flexibelsten auch wenn es nicht die schönste Lösung ist wie wir ja schon festgestellt haben da das Journal die ganze Zeit beobachtet wird. Hier kann ich aber Loggen was ich möchte im Gegensatz zu allen Varianten die durch die Unit gesteuert werden.

Bei deiner systemd Lösung besteht ja scheinbar noch ein Bug, also läuft das vermutlich auch nicht 100 % rund soweit ich das aus dem Kontext herauslesen konnte. Daher habe ich das jetzt nicht weiterverfolgt. Bitte nicht böse sein.

Bei der Lösung von NAB systemd kombiniert mit dem letzten Skript funktioniert alles bis auf die kleinigkeit das er Benachrichtigt bei einem Ende durch den User. Denke mal das kann man auch noch ändern.

Ziel meines Anliegen war bei einem Fehler der Homebridge Instanz benachrichtig zu werden, ich glaube das Ziel haben wir schon mehrfach erreicht

Also zurück zu deiner Frage, ja klar möchte ich wenn möglich noch auf andere Ereignisse reagieren nach dem hier schon so viel erreicht wurde bin ja neugierig was geht oder was nicht aber es sollte auch nicht aus dem Ruder laufen was denn Schwierigkeitsgrad angeht.
Von allen Lösungen habe ich diese Funktion bisher nur bei der Möglichkeit mit dem reporter.sh und dem Loggen des Journal.

Code: Alles auswählen

Und hast du noch immer deine 23 systemd-Units, oder hast du schon eine instanziierende, mit der du deine 23 Homebridge-Services aufrufst?

Hatte ich komplett umgestellt auf einem Backup Image zum testen, auch hier bin ich ganz ehrlich ich konnte für meinen Zweck keinen riesen Vorteil finden da ich die Service Dateien in der Regel so gut wie nie anfasse. Die Befehle sind ja vom Grundsatz alle gleich geblieben statt einem - hatte ich dann ein @ beim starten und stoppen der Units.

Vielleicht habe ich ja auch den Vorteil noch nicht ganz Verstanden für meinen Anwendungsfall ?

[scientific]

Runuser führt man nur als root aus. Wenn dein Service als root läuft, verwende runuser statt sudo oder su um einen Befehl dann als anderer User (in deinem Fall pi) auszuführen.

Wenn du es testen willst, werde mit su oder sudo im Terminal zu root, und dann führe den runuser-Befehl wie oben aus.

Ich verstehe, dass du verwirrt bist... so viele schöne Lösungen... und eine Entscheidung ist immer ein Massenmord an Möglichkeiten...

Der Bug mit OnFailure ist zwar "lästig", wird aber mit der Konstruktion die ich dir vorgestellt habe, abgefangen. Das ist alles. Sollte das einmal behoben werden in systemd kann der Aufruf in der aufgerufenen Unit auch vereinfacht werden, da dann nur mehr einmal beim endgültigen Failure einer Unit eine Folgeunit gestartet wird... Für meinen Begriff kann man damit gut arbeiten. Vor allem wenn es darum geht, eine Benachrichtigung zu versenden, wenn ein Dienst fehlschlägt. Wie das geht, hab ich dir gezeigt. Zwei kleine Units und ein kurzes Shellskript. Kein ständiges Parsen des Journals usw...

Ich versteh auch nicht ganz, wozu du so "flexibel" sein musst um auf alles mögliche zu reagieren, wenn du eh nur eine Nachricht erhalten willst, wenn ein Homebridge-Service ausfällt...
Mit meiner Lösung kannst du dir von jedem einzelnen Dienst eine telegram-Nachricht schicken lassen, indem du ein Drop-In mit zwei Zeilen in /etc/systemd/system/ueberwachter.service.d/ ablegst... Mit deiner "flexiblen" Lösung musst du bei jeder neuen Unit dein Skript, die Parsoptionen fürs Journal usw. anpassen... Das musst du bei meiner Lösung nicht.

Der Vorteil an den instantiierenden Units liegt genau darin, dass du eine Änderung z.B. an der Abhängigkeit einer Überwachungs-Unit diese in einem einzigen File anpassen musst, und nicht in 23 verschiedenen. Das DropIn machst du ebenfalls nur für die instantiierende Unit und nicht für jede einzelne aufgerufene Instanz.

Wird der Service regulär beendet, kommt keine Nachricht. Das hast du ja manuell gemacht. Fällt der Service aus und kann nicht mehr restartet werden, kommt die Nachricht. Kommt der Service beim Booten nicht hoch, kommt die Nachricht. Zwei kleine Units... und du hast für jeden Service eine Überwachung parat.

lg scientific

[NAB]

Edit: Es gibt einmal diesen beim manuellen beenden:

Code: Alles auswählen

Mär 20 07:07:04 HomeBridgeServer homebridge[18513]: [2018-3-20 07:07:04] Got SIGTERM, shutting down Homebridge...
Mär 20 07:07:04 HomeBridgeServer systemd[1]: homebridge-test.service: Main process exited, code=exited, status=143/n/a
Mär 20 07:07:04 HomeBridgeServer sudo[18646]:     root : TTY=unknown ; PWD=/ ; USER=pi ; COMMAND=/usr/local/bin/benachrichtigung.sh homebridge-test.service 30
Mär 20 07:07:04 HomeBridgeServer sudo[18646]: pam_unix(sudo:session): session opened for user pi by (uid=0)
Mär 20 07:07:04 HomeBridgeServer sudo[18653]:       pi : TTY=unknown ; PWD=/ ; USER=pi ; COMMAND=/usr/local/bin/ntfy -b telegram send Dienst homebridge-test.service ausgefallen mit exit-code 143
Mär 20 07:07:04 HomeBridgeServer sudo[18653]: pam_unix(sudo:session): session opened for user pi by (uid=0)
Mär 20 07:07:05 HomeBridgeServer systemd[1]: Stopped homebridge-test.service.
Mär 20 07:07:05 HomeBridgeServer systemd[1]: homebridge-test.service: Unit entered failed state.
Mär 20 07:07:05 HomeBridgeServer systemd[1]: homebridge-test.service: Failed with result 'exit-code'.

Aha? Das ist komisch. In meinen Primitiv-Tests hat er sich mit "success" beendet, wenn ich den Service mit systemctl stop beendet habe. Oder wie beendest du "manuell"?

Wie auch immer ... den Fall könnte man abfangen. Das Ende vom Script sähe dann so aus:

Code: Alles auswählen

if [ "$SERVICE_RESULT" == "success" ]; then
   exit 0 # Keine Nachricht bei erfolgreicher Beendigung
fi

if [ "$SERVICE_RESULT" == "exit-code" ] && [ "$EXIT_STATUS" == "143" ]; then
   exit 0 # Keine Nachricht bei SIGTERM
fi

# Zeitstempel existiert nicht oder ist zu alt. Neuer Zeitstempel wird erzeugt:
echo $(date +"%s") > $zeitstempel

# Debug
# echo /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS" >> $arbeitsverzeichnis/debug.txt

sudo -u pi /usr/local/bin/ntfy -b telegram send "Dienst $dienst ausgefallen mit $SERVICE_RESULT $EXIT_STATUS"

(Das sudo würde ich da ganz gerne auch wieder rauskriegen, aber im Moment ist es ganz praktisch, weil es dir im journal hinterlässt, was das Script so treibt. Darum kümmern wir uns später.)

Gerade wenn man bereits Systemd nutzt, und ein Systemd-Unit hat, dann kann man doch auch dynamische Nutzer generieren lassen. Alternativ kann man Systemdienste auch mittels Rootrechten starten, und hinterher die Rechte wieder automatisch gemäß "man systemd.exec" entziehen lassen. Zumal ein mittels Rootrechten gestarteter Prozess, die Privilegien eines Root nicht dauerhaft oder gar in vollem Umfang benötigt. Von daher ist das eine praktische Sache, die auch noch weitere Restriktionen ermöglicht.

Stimmt. Aber ich schmiere hier in einer fremden Unit rum, die anscheinend als "root" laufen muss. Lediglich das ExecStopPost= soll als User "pi" laufen. Und ich möchte die fremde Unit so wenig wie möglich verunstalten.

[Nastra]

@NAB

Code: Alles auswählen

Oder wie beendest du "manuell"?

sudo systemctl stop homebridge-test

Code: Alles auswählen

Das Ende vom Script sähe dann so aus:

Teste ich nachher

@scientific

Code: Alles auswählen

Wenn du es testen willst, werde mit su oder sudo im Terminal zu root, und dann führe den runuser-Befehl wie oben aus.

Funktioniert als root

Code: Alles auswählen

ch verstehe, dass du verwirrt bist... so viele schöne Lösungen... und eine Entscheidung ist immer ein Massenmord an Möglichkeiten...  :wink: 

Da sagst du was!

Code: Alles auswählen

Ich versteh auch nicht ganz, wozu du so "flexibel" sein musst um auf alles mögliche zu reagieren

Es gibt einige Fehler, die auftreten ohne denn Service zu beenden, wenn z.B. eine Zigbee Bridge von Philips Hue nicht erreichbar ist oder ähnlichem. Oder so etwas hier wenn nach einem Update vom Entwickler ein Fehler eingebaut wurde versehentlich:

Code: Alles auswählen

HomeKitServer homebridge[31128]: (node:31128) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)

Da ist die Flexibiltät vom großen Vorteil.

Der Vorteil an den instantiierenden Units liegt genau darin, dass du eine Änderung z.B. an der Abhängigkeit einer Überwachungs-Unit diese in einem einzigen File anpassen musst, und nicht in 23 verschiedenen. Das DropIn machst du ebenfalls nur für die instantiierende Unit und nicht für jede einzelne aufgerufene Instanz.

Ja so hatte ich es auch verstanden, dann habe ich doch nicht so falsch gelegen. Wie gesagt ist zwar ganz nett und bestimmt auch hilfreich wenn man öfter was ändert an denn Units, ist bei mir aber nicht der Fall. Das hinzufügen von neuen Instanzen / Servicen kommt auch relativ selten vor.
Sehe daher keinen Riesen Gewinn für mich alles mit den instantiierende Unit zu machen.

Noch ein Grund ist das bei uns im HomeKit Forum einer verschiedene Wartungstools zum Hinzufügen von neuen Instanzen etc. geschrieben hat was auf die jetzige Basis aufbaut.

Aber es ist trotzdem gut im Hinterkopf zu wissen das es möglich ist.

[scientific]

In /etc/systemd/system sammeln sich ja doch mit der Zeit so einige Files und Links an... Und wenn man da 23 Files auf ein einziges reduzieren kann, dient es der Übersichtlichkeit.

Angenommen, du willt die Services mit einem anderen target starten lassen, musst du 23 Files ändern.

Diese Fehlermeldung... Da ist ein Device nicht erreichbar, aber der Service läuft trotzdem weiter. Und dafür willst du eine Benachrichtigung. Versteh ich das richtig?

[Nastra]

Code: Alles auswählen

In /etc/systemd/system sammeln sich ja doch mit der Zeit so einige Files und Links an... Und wenn man da 23 Files auf ein einziges reduzieren kann, dient es der Übersichtlichkeit.

Das kann gut möglichsein, aber du musst dir das so vorstellen das ich mit dem Rechner nichts mache also nicht Arbeiten etc. Er steht einfach nur still in der Ecke und verarbeitet Befehle die er vom Apple TV bzw. HomeKit erhält ein Gerät zu triggern ein Homebridge Server halt. Daher sammelt sich eigentlich auch nichts neues, außer das System produziert Datenmüll wovon ich nicht ausgehe?

Code: Alles auswählen

Angenommen, du willt die Services mit einem anderen target starten lassen, musst du 23 Files ändern.

Wüsste nicht wann und wofür

Code: Alles auswählen

Diese Fehlermeldung... Da ist ein Device nicht erreichbar, aber der Service läuft trotzdem weiter. Und dafür willst du eine Benachrichtigung. Versteh ich das richtig?

Genau, bei dem Beispiel von oben handelt es sich um ein Rollo. Wenn da ein Fehler auftitt würde ich das gerne vor meiner Frau mitbekommen bevor ich mir wieder anhören muss scheiß Technik brauch kein Mensch geht wieder nicht

[NAB]

Wüsste nicht wann und wofür

Eben gerade dann zum Beispiel,wenn du nun in jede Unit die ExecStopPost= Zeile einbauen müsstest, um dich beim Ausfall benachrichtigen zu lassen. Wenn du mit nur einer instantiierenden Unit arbeitest, dann müsstest du nur eine Unit ändern.

Auf der anderen Seite könntest du mit nur einer instantiierenden Unit keine individuellen Nachrichtenlimits eintragen (falls du das willst). Außer wir packen das Nachrichtenlimit auch ins Environment (von dem ich keine Ahnung habe).

Es hat also alles so seine Vor- und Nachteile ...

[Nastra]

Ihr macht mich fertig

Ich denke ich bleibe aus denn oben genannten Gründen bei der Variante die ich jetzt habe. Auch wenn ich das Nachrichtenlimit 20 mal ändern muss. Das mach ich einmal und nie wieder da ansonsten kein Änderungsbedarf mehr bestehen dürfte. Glaube das werde ich verkraften.
Außerdem sollte ich diese Lösung bei uns im Forum ggf. veröffentliche (vorausgesetzt du / ihr seit damit noch einverstanden) und Schreibe dann dabei ihr müsst euer ganzes Setup / Instanzen umbauen sind die meisten glaube ich damit überfordert oder lassen es direkt sein. Das ist ja auch nicht Ziel der Sache.

Ist wie du gesagt hast, es hat alles seine Vorteile und Nachteile hiermit habe ich mich entschieden.



Ich hätte aber noch eine Frage, wenn ich die letzte Lösung von dir nutze NAB würde ich ja gerne parallel auch noch andere Ereignisse Überwachen was über die Unit nicht möglich ist. Würde für mich bedeuten ich müsste ggf. das reporter.sh Skript parallel betreiben.
Hier sehe ich aber das Problem dass ich im reporter.sh nach dem Begriff error suchen würde um kleinere Fehler zu finden. Kommt es zu einem Absturz der Instanz würde ich einmal durch die Unit und nochmal durch denn reporter.sh benachrichtigt werden.

Da die kleineren Fehler nicht ganz so akut sind wie wenn ein Service ausfällt und nichts mehr geht würde es wohlmöglich reichen einmal am Tag vorzugsweise per Telegram oder Email das error Log gesendet zu bekommen. Ich denke das wäre so das Optimale um eine Doppel Benachrichtigung und das Überwachen des Journal zu vermeiden und trotzdem auf dem laufenden zu bleiben.

Kennt einer von euch dafür eventuell eine Lösung.

[scientific]

Hmmm... Gerade wenn du deine Lösung veröffentlichst, wäre wohl die professionellere Geschichte jene mit den instanziierenden Units.

Hab ich das richtig verstanden, da baut einer ein Skript, das Unitfiles ausspuckt? Genau um sowas zu vermeiden, wurden die instanziierenden Units erfunden.

Aber bitte.

[NAB]

Ich hätte aber noch eine Frage, wenn ich die letzte Lösung von dir nutze NAB würde ich ja gerne parallel auch noch andere Ereignisse Überwachen was über die Unit nicht möglich ist. Würde für mich bedeuten ich müsste ggf. das reporter.sh Skript parallel betreiben.
Hier sehe ich aber das Problem dass ich im reporter.sh nach dem Begriff error suchen würde um kleinere Fehler zu finden. Kommt es zu einem Absturz der Instanz würde ich einmal durch die Unit und nochmal durch denn reporter.sh benachrichtigt werden.

Das liegt nun wiederum bei dir, durch geschickt formulierte grep-Abfragen genau die Ereignisse herauszupicken, auf die du reagieren möchtest ... und auf keine zusätzlichen. Ohne konkrete Beispiele kann man dir da auch nicht helfen ... ich kann ja nicht hellsehen.

Da die kleineren Fehler nicht ganz so akut sind wie wenn ein Service ausfällt und nichts mehr geht würde es wohlmöglich reichen einmal am Tag vorzugsweise per Telegram oder Email das error Log gesendet zu bekommen. Ich denke das wäre so das Optimale um eine Doppel Benachrichtigung und das Überwachen des Journal zu vermeiden und trotzdem auf dem laufenden zu bleiben.

Kennt einer von euch dafür eventuell eine Lösung.

Das war Variante drei, die ich im Kopf hatte.

Die nötigen Bauteile dazu kennst du eigentlich schon. Man kann jounralctl fragen, was bei einer bestimmten Unit oder einer Gruppe von Units in den letzten 24 Stunden so los war (oder auch in den letzten 10 Minuten). Das müsste man dann alle 24 Stunden tun (oder halt alle 10 Minuten), per TimerUnit. Der Trick wäre dann mal wieder, sich mit grep die gewünschten Zeilen herauszupicken und sie dir zuzusenden. Insbesondere bei ntfy weiß ich nicht, ob die Nachrichten überhaupt mehrere Zeilen haben dürfen und wie lang die sein dürfen.

Da solltest du erst mal gründlich drüber nachdenken, was du eigentlich haben willst. Mit 200 Zeilen Log-Auszug der letzten 24 Stunden ist dir auf dem Schlaufon vermutlich auch nicht gedient. Und eigentlich interessiert es morgens auch nicht mehr, ob letzten Vormittag das Rollo ausgefallen war, oder?

[Nastra]

Hast recht, die meisten Sachen stehen mir hier ja schon zu Verfügung. Hatte erst vor mich die Tage mal dranzusetzen und zu schauen ob ich selber was gebastelt bekomme aber eigentlich bin ich von der Idee auch nicht mehr richtig überzeugt umso mehr ich dadrüber nachdenken. Vermutlich ist es ja so wie du sagst über Telegram gibt es ein Zeichen Limit und was interessiert mich heute wenn gestern was nicht ging.

Die Reporter Lösung ist wie schon öfter erwähnt vermutlich nicht das Gelbe vom Ei mit der Journal Überwachung, deckt aber alles was ich benötige relativ unkompliziert ab daher werde ich diese wohl beibehalten.

Werde deine zweite Lösung später trotzdem aus interesse noch zu ende ausprobieren.

[scientific]

Ich hab ja bzgl OnFailure einen Bugreport bei systemd auf github erstellt.

https://github.com/systemd/systemd/issu ... -377026262

Nun, Pöttering hat ihn akzeptiert und vor 9 Tagen als Milestone für v239 hinzugefügt.

Samma gspannt, wann 239 in Debian aufschlägt.

lg scientific