Gelöst! Shell Skript für systemd Überwachung
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
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.
Ja, ich würds tun!
Runuser wird aus den Quellen von su gebaut und ist speziell für diese Zwecke.
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Gelöst! Shell Skript für systemd Überwachung
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: 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: 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
Diese Zeile:
Code: Alles auswählen
ExecStopPost=/bin/sh -c "/usr/bin/sudo -E -u pi /usr/local/bin/benachrichtigung.sh %n 1200"
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 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
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.Nastra hat geschrieben:18.03.2018 18:14:08der exit-code 1 ist nur bei ausstieg mit FAILURE richtig? Ist es ggf. möglich das "FAILURE" mit in der Nachricht einzublenden?
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
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.
Wenn du mehr überwachen willst, würd ich ein Monitoring-System wie z. B. Zabbix installieren.
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
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
Wenn du deine Systeme beim Leben beobachten willst, ist das eine gute Wahl.
Lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Gelöst! Shell Skript für systemd Überwachung
Moin Moin,
@NAB Danke für die Ausführlich Antwort und Erklärung
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
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..
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
Völlig richtig
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?
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:
und diesen wenn ein Fehler aufgetreten ist:
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.
Deswegen bin ich ja hier um mir Fachkundigen Rat zu holen
Da hätte man auch selber drauf kommen können
@scientific
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?
und
Danke euch beiden!
Lg Nastra
@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.
Code: Alles auswählen
Aus welchen Gründen kann so eine homebridge sich eigentlich beenden?
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.
Code: Alles auswählen
und geht mal dezent davon aus, dass "pi" ein Home-Verzeichnis hat
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?
Code: Alles auswählen
Mit welchem $SERVICE_RESULT können sich deine Dienste überhaupt beenden?
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'.
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.
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:
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.
@scientific
Code: Alles auswählen
Wenn du mehr überwachen willst, würd ich ein Monitoring-System wie z. B. Zabbix installieren.
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"
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
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
Bei mir kommt in einr Rootshell ausgeführt
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
Code: Alles auswählen
runuser -u scientific -- /usr/local/bin/ntfy -b telegram send 'Bla'
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
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: Gelöst! Shell Skript für systemd Überwachung
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.NAB hat geschrieben:18.03.2018 20:33:32Diese Zeile: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".Code: Alles auswählen
ExecStopPost=/bin/sh -c "/usr/bin/sudo -E -u pi /usr/local/bin/benachrichtigung.sh %n 1200"
Re: Gelöst! Shell Skript für systemd Überwachung
@scientific
habe ich gemacht, hier das Ergebnis. Irgendwie hat er noch was zu meckern.
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.
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 ?
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?
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?
Vielleicht habe ich ja auch den Vorteil noch nicht ganz Verstanden für meinen Anwendungsfall ?
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
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
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
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Gelöst! Shell Skript für systemd Überwachung
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"?Nastra hat geschrieben:20.03.2018 04:41:56Edit: 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'.
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"
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.breakthewall hat geschrieben:20.03.2018 10:24:41Gerade 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.
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: Gelöst! Shell Skript für systemd Überwachung
@NAB
sudo systemctl stop homebridge-test
Teste ich nachher
@scientific
Funktioniert als root
Da sagst du was!
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:
Da ist die Flexibiltät vom großen Vorteil.
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.
Code: Alles auswählen
Oder wie beendest du "manuell"?
Code: Alles auswählen
Das Ende vom Script sähe dann so aus:
@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.
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:
Code: Alles auswählen
Ich versteh auch nicht ganz, wozu du so "flexibel" sein musst um auf alles mögliche zu reagieren
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)
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.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.
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.
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
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?
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?
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Gelöst! Shell Skript für systemd Überwachung
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.
Code: Alles auswählen
Angenommen, du willt die Services mit einem anderen target starten lassen, musst du 23 Files ändern.
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?
Re: Gelöst! Shell Skript für systemd Überwachung
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 ...
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: Gelöst! Shell Skript für systemd Überwachung
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.
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.
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
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.
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.
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Gelöst! Shell Skript für systemd Überwachung
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.Nastra hat geschrieben:20.03.2018 17:51:55Ich 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 war Variante drei, die ich im Kopf hatte.Nastra hat geschrieben:20.03.2018 17:51:55Da 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.
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?
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: Gelöst! Shell Skript für systemd Überwachung
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.
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.
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Gelöst! Shell Skript für systemd Überwachung
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
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
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main