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

[NAB]

Danke für die Links, ich habe das Skript zum testen jetzt angepasst, es läuft auch und reagiert auf die homebridge Meldung. Beim Backup was ich zum testen mit reingenommen habe reagiert er nicht.

Du meinst, das Script, so wie es da steht, reagiert auf "homebridge-test"? Das überrascht mich etwas ... aber schauen wir mal ...

Ich vermute mal das es jetzt was mit dem Inhalt der Unit zutun hat? Oder ist ein Fehler im Skript?

Skript:

Code: Alles auswählen

#!/bin/bash                                                                                                  
journalctl -u homebridge-test -u backup -f --since "now" |                                                                     
grep --line-buffered "code=exited|USB-stick"                                                                      
sudo -u pi xargs -L1 -t -I '$' ntfy -b telegram send 'Achtung - ''$'

Mit der Unit dürfte das nichts zu tun haben. Die soll ja nur das Script starten, daran hat sich nichts geändert. Allerdings startet deine Unit kein "backup.service". Dass "backup.service" laufen muss, damit du Nachrichten von "backup" bekommst, ist logisch, ja?

Ich vermute, es liegt am Script. Du kannst mal wieder ne Trockenübung machen:

Code: Alles auswählen

journalctl -u homebridge-test -u backup -f --since "now"

Du solltest eigentlich Meldungen von "homebridge-test" und "backup" sehen können. Klappt das? Wenn vorne nichts reinkommt, kann hinten ja auch nichts rauskommen.

Mit dem grep hast du schon eine gute Idee gehabt ... so ähnlich hatte ich mir das auch vorgestellt. Aber ... ich mach da mal ne Trockenübung, ja?

Code: Alles auswählen

$ echo -e "eins\nzwei\ndrei"
eins
zwei
drei

Gut, so gibt er mir schon mal drei Zeilen aus. Jetzt nehme ich grep dazu:

Code: Alles auswählen

$ echo -e "eins\nzwei\ndrei" | grep --line-buffered "eins"
eins

Geht! Und jetzt mit dem senkrechten Strich (der hat für grep nämlich auf einmal ne andere Bedeutung, nämlich "oder"):

Code: Alles auswählen

$ echo -e "eins\nzwei\ndrei" | grep --line-buffered "eins|drei"
$

Das klappt bei mir gar nicht. Du erzählst, es klappt bei dir zur Hälfte ... das wundert mich. Eigentlich weiß grep nämlich gar nicht, dass der senkrechte Strich eine besondere Bedeutung hat. Eventuell hast du ein anderes grep als ich?

Es gibt hier zwei mögliche Schreibweisen. Die erste ist, dass wir grep mit einem -e sagen, wonach es suchen soll. Und -e darf man wieder mehrmals verwenden:

Code: Alles auswählen

$ echo -e "eins\nzwei\ndrei" | grep --line-buffered -e "eins" -e "drei"
eins
drei

Die zweite ist, dass wir grep mit einem großen -E sagen, dass es den senkrechten Strich als "oder" auffassen soll:

Code: Alles auswählen

$ echo -e "eins\nzwei\ndrei" | grep --line-buffered -E "eins|drei"
eins
drei

Welche Variante du nun nimmst, ist Geschmackssache. Ich finde die erste übersichtlicher ... gerade wenn dein Script nach noch mehr Schlüsselworten suchen soll.

P.S.: Was die Sache mit der Systemd-Unit angeht ... ist /usr/local/bin/deamon.sh ausführbar? Also klappt
sudo /usr/local/bin/deamon.sh
?

[TomL]

Ok... also noch mal im einzelnen...

Es gibt verschiedene Möglichkeiten zur Lösung dieses Problems:
1. Zyklisch per cron einen Journal-Grep-Auswerte-Job starten und bei gefundenen Problemen etwas tun. Das geht, ist aber eine dumme Lösung, die aufwendig auswerten muss, weil ja auch mehrere Prozesse sterben können.
2. Einen Daemon installieren, also ein Programm, welcher permanent im Hintergrund läuft und "journalctl -f" mit "grep" auswertet, was m.M.n. so ziemlich die dümmste Lösung überhaupt ist.

Diese beiden ersten Varianten sind sowas wie pseudo-Eventhandler... also ganz ähnlich wie ein Marathon-Läufer auf Krücken.

3. Den Eventhandler von systemd selber nutzen, weil es den genau für diesen Zweck gibt.

Die dritte Variante ist die richtige Lösung, als vergiss das mit dem Daemon... ein solche Lösung ist Schrott! Lege die beiden folgenden Dateien an. Zuerst das Script, welches hier nur einen Log-Eintrag schreibt. Aber da kannst Du alles, was Du willst, eintragen oder lösen lassen, eben auch das Senden einer Nachricht per Telegram. Ich habe diese ntf-Zeile da reinkopiert, aber mit # kommentiert, weil ich die Syntax nicht kenne.

Code: Alles auswählen

nano /usr/local/bin/instanzen-reporter

Code: Alles auswählen

#!/bin/bash

echo "Send Message $1 exited" | systemd-cat -t "$(basename $0)" -p "info"
#ntfy -b telegram send '$1 Instanz ausgefallen'

exit 0

Und als nächstes die Service-Unit, die das Script automatisch bei einem Ausfall-Event startet:

Code: Alles auswählen

nano /etc/systemd/system/instanzen-reporter@.service

Code: Alles auswählen

[Unit]
Description=Sende Nachricht über ausgefallene Prozesse

[Service]
Type=oneshot
RemainAfterExit=no

ExecStart=/usr/local/bin/instanzen-reporter %I 

[Install]
WantedBy=multi-user.target

Die Besonderheit ist hier die mit @ vorgegebene Instantiierung, die eine Unit mehrfach nutzbar macht... also auf das Zeichen @ achten! Jetzt brauchst Du nur noch in jede zu überwachende Service-Unit das folgende Statement in der Unit-Section eintragen, jeweils mit einem eigenem Instanz-Namen. Ich würde hier den Namen des überwachten Services nehmen... als 1 Wort

1.Unit für den Dienst homebridge

Code: Alles auswählen

OnFailure=instanzen-reporter@homebridge.service

2. Unit für den Dienst pusemuckel

Code: Alles auswählen

OnFailure=instanzen-reporter@pusemuckel.service

3. Unit für den Dienst irgendwas

Code: Alles auswählen

OnFailure=instanzen-reporter@irgendwas.service

Du solltest Dich nur an die von mir gewählten Pfade halten, weil das auch die Defaultpfade sind, mit denen es sofort funktioniert. Die Rechte für Script und Service sind root:root, das Script 755, die Service-Unit 644.... bitte unbedingt dran halten.

Das wars... mehr ist nicht notwendig.... Darüber hinaus musst Du -sofern das notwendig ist- nur noch das Script anpassen.

[Nastra]

Hey ho,

vielen Dank für die schnellen Antworten euch beiden!

@TomL Es funktioniert so wie du es diesmal beschrieben hast war es auch für einen nicht so versierten
Linux User wie mich sofort nachvollziehbar. Klasse!

Zwei Dinge hätte ich noch auf dem Herzen,

1.)

Die Besonderheit ist hier die mit @ vorgegebene Instantiierung, die eine Unit mehrfach nutzbar macht... also auf das Zeichen @ achten! Jetzt brauchst Du nur noch in jede zu überwachende Service-Unit das folgende Statement in der Unit-Section eintragen, jeweils mit einem eigenem Instanz-Namen. Ich würde hier den Namen des überwachten Services nehmen... als 1 Wort

Unit für den Dienst homebridge
CODE: ALLES AUSWÄHLEN
OnFailure=instanzen-reporter@homebridge.service

Wenn ich dich richtig verstehe sollte in der Unit der jeweiligen Homebridge Instanz die Zeile in der Section Unit so aussehen bzw. ergänzt werden gem. deinem Beispiel?

Code: Alles auswählen

[Unit]
Description=homebridge-test.service 
After=syslog.target network-online.target
OnFailure=instanzen-reporter@homebridge-test.service

[Service]
Type=simple
User=root
EnvironmentFile=/etc/default/homebridge-test
ExecStart=/usr/bin/homebridge $HOMEBRIDGE_OPTS
Restart=on-failure
RestartSec=10
KillMode=process
ExecStartPre= 

[Install]
WantedBy=multi-user.target

Bei mir hat es nur funktioniert wenn ich die Zeile so eingefügt habe ohne das @:

Code: Alles auswählen

OnFailure=instanzen-reporter

mit @ habe ich diese Fehlermeldung wieder bekommen:

Code: Alles auswählen

homebridge-test.service: Failed to enqueue OnFailure= job: No such file or directory

2.) Bei der Skript Lösung hatte ich zum Schluss die komplette Ausgabe der Journal Zeile im Telegram Messenger:

Code: Alles auswählen

Achtung - Mär 01 17:01:02 HomeKitServer systemd[1]: homebridge-test.service: Main process exited, code=exited, status=143/n/a

Wie müsste ich jetzt in dem Skript von dir die Zeile für ntfy anpassen, habe schon die Sachen ausprobiert die ich mit @NAB gemacht habe aber da scheint wohl ein unterschied zu sein zu xargs? Das mochte er garnicht

So sieht diese zurzeit aus:

Code: Alles auswählen

sudo -u pi ntfy -b telegram send 'Instanz ausgefallen'

@NAB Deine Antwort bzw. das Prüfen des Skript werde ich wohl aufs We verschieben müssen, da es jetzt schon spät ist und morgen die Familie mich größtenteils gebucht hat

lg

[TomL]

Wenn ich dich richtig verstehe sollte in der Unit der jeweiligen Homebridge Instanz die Zeile in der Section Unit so aussehen bzw. ergänzt werden gem. deinem Beispiel?

Code: Alles auswählen

[Unit]
Description=homebridge-test.service 
After=syslog.target network-online.target
OnFailure=instanzen-reporter@homebridge-test.service
:::

Ja, genau so ist es richtig! Die Unit instanzen-reporter@.service wird damit unter dem Namen instanzen-reporter@ homebridge-test.service gestartet. Als Instanzname dieser gestarteten Unit wird hier "homebridge-test" verwendet. Instanzname bedeutet, man kann die gleiche Unit unter verschiedenen Namen starten, jede Instanz mit einem eigenen Namen.... und ganz am Ende dabei an den Parameter %I denken, der auch den Instanznamen enthält und der in der gestarteten Unit zur Übergabe an das Script weiterverwendet wird.

Bei mir hat es nur funktioniert wenn ich die Zeile so eingefügt habe ohne das @:

Code: Alles auswählen

OnFailure=instanzen-reporter

mit @ habe ich diese Fehlermeldung wieder bekommen:....

Dieses OnFailure-Statement ist so falsch. Damit würde die Unit "static" aufgerufen werden und Du kannst hierbei keine Nachricht übergeben, welcher Dienst ausgefallen ist, wozu ja der Instanzname verwendet wird. Wenn der o.g. Fehler entsteht, wurde die Instanz-Unit nicht gefunden und Du hast vermutlich irgendwo einen Fehler eingebaut. Kontrolliere mal, ob es diese Datei gibt, das ist die Unit, die gestartet wird bzw. gestartet werden soll.... und auch hier auf das @ achten:

Code: Alles auswählen

cat /etc/systemd/system/instanzen-reporter@.service

Erst dieses @ ermöglicht, dass diese Unit unter dem übergebenen Instanz-Namen gestartet wird. Uns interessiert aber hier an dieser Stelle nicht der Instanz-Name und das die Unit unter diesem Namen läuft, sondern der unter %I übergebene Name wird einfach weitergegeben an das Script, welches damit den Namen des ausgefallenen Dienstes erfährt und seine Telegram-Nachticht senden kann.

[Nastra]

Nach dem ich das vergessene @ mit in den Namen aufgenommen habe beim reporter

Code: Alles auswählen

instanzen-reporter@.service

funktioniert es auch mit der Zeile

Code: Alles auswählen

OnFailure=instanzen-reporter@homebridge-test.service

in der Homebridge Unit.

Code: Alles auswählen

pi@HomeKitServer:~ $ sudo cat /etc/systemd/system/instanzen-reporter@.service
[Unit]
Description=instanzen-reporter@.service

[Service]
Type=oneshot
RemainAfterExit=no

ExecStart=/usr/local/bin/instanzen-reporter %I

[Install]
WantedBy=multi-user.target

Ich bekomme jetzt als Push Nachricht das hier ausgegeben:

Code: Alles auswählen

$1 Instanz ausgefallen

das $ Zeichen ist ja mit in der Nachricht, hätte es jetzt eher außerhalb erwartet im Code. Hat es eine bestimmte Bedeutung an dieser Stelle?

Was mir jetzt auch noch nicht richtig klar ist an welcher Stelle genau das

Code: Alles auswählen

%I

zusätzlich eingetragen werden muss das der Name übernommen wird. Bisher steht es nur hier in der oben gezeigten

Code: Alles auswählen

instanzen-reporter@.service

Unit unter

Code: Alles auswählen

ExecStart=/usr/local/bin/instanzen-reporter %I

Ich habe es hier probiert, ging natürlich wieder nicht

Code: Alles auswählen

OnFailure=instanzen-reporter@homebridge-test.service %I

oder hier

Code: Alles auswählen

OnFailure=instanzen-reporter@homebridge-test%I.service

[Nastra]

@NAB

Habe gerade unverhofft doch noch etwas Zeit gefunden an unserem Skript weiter zu testen

Also ich denke ich habe den Fehler gefunden weswegen es scheinbar bei mir ging mit

Code: Alles auswählen

"code=exited|USB-stick"

eigentlich geht es doch nicht, ich vermute das ich vergessen habe den Instanzen-reporter.service einen restart zu verpassen das er die alten Daten gezogen hatte und ich es nicht mitbekommen habe. Daher auch keine Reaktion auf Backup auch wenn ich dieses über die Unit gestartet hatte.

Ich habe das Skript testweise mit der neuen Zeile ausgestattet

Code: Alles auswählen

#!/bin/bash                                                                                                  
journalctl -u homebridge-test -u homebridge-hue -f --since "now" |                                                                     
grep --line-buffered -e "exit" -e "exited"                                                                       
sudo -u pi xargs -L1 -t -I '$' ntfy -b telegram send 'Achtung - ''$'

diese funktioniert auch gem. Status und er findet die Suchbegriffe aber nicht getrennt für die einzelnen Units. Also er sucht in beiden Units nach beiden Suchbegriffen.

Code: Alles auswählen

pi@HomeKitServer:~ $ sudo systemctl status reporter-homebridge.service
● reporter-homebridge.service
   Loaded: loaded (/etc/systemd/system/reporter-homebridge.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-03-02 08:50:25 CET; 38s ago
 Main PID: 18734 (reporter-homebr)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/reporter-homebridge.service
           ├─18734 /bin/bash /usr/local/bin/reporter-homebridge.sh
           ├─18735 journalctl -u homebridge-test -u homebridge-hue -f --since now
           └─18736 grep --line-buffered -e exit -e exited

Mär 02 08:50:25 HomeKitServer systemd[1]: Started reporter-homebridge.service.
Mär 02 08:50:43 HomeKitServer reporter-homebridge.service[18734]: Mär 02 08:50:43 HomeKitServer systemd[1]: homebridge-hue.service: Main process exited, code=exited, status=143/n/a
Mär 02 08:50:43 HomeKitServer reporter-homebridge.service[18734]: Mär 02 08:50:43 HomeKitServer systemd[1]: homebridge-hue.service: Failed with result 'exit-code'.
Mär 02 08:50:55 HomeKitServer reporter-homebridge.service[18734]: Mär 02 08:50:55 HomeKitServer systemd[1]: homebridge-test.service: Main process exited, code=exited, status=143/n/a
Mär 02 08:50:55 HomeKitServer reporter-homebridge.service[18734]: Mär 02 08:50:55 HomeKitServer systemd[1]: homebridge-test.service: Failed with result 'exit-code'.

Es wird aber keine Pushnachricht mehr erzeugt? Ich gehe mal davon aus das jetzt

Code: Alles auswählen

sudo -u pi xargs -L1 -t -I '$' ntfy -b telegram send 'Achtung - ''$'

nicht mehr passt und geändert werden muss?

[TomL]

Ich bekomme jetzt als Push Nachricht das hier ausgegeben:

Code: Alles auswählen

$1 Instanz ausgefallen

das $ Zeichen ist ja mit in der Nachricht, hätte es jetzt eher außerhalb erwartet im Code. Hat es eine bestimmte Bedeutung an dieser Stelle?

Was mir jetzt auch noch nicht richtig klar ist an welcher Stelle genau das

Code: Alles auswählen

%I

zusätzlich eingetragen werden muss das der Name übernommen wird. Bisher steht es nur hier in der oben gezeigten

Code: Alles auswählen

instanzen-reporter@.service

Unit unter

Code: Alles auswählen

ExecStart=/usr/local/bin/instanzen-reporter %I

Genau so ist es richtig und nur dort darf %I stehen. $1 und %I sind im übertragenen Sinn Variablen, die einen an eine Prozedur (resp. Unit) übergebenen Wert enthalten. Du kannst das Testen. Starte dazu zuerst ein Terminal, melde dich als root an und starte diesen Befehl:

Code: Alles auswählen

/usr/local/bin/instanzen-reporter TestNachricht

Dabei wird der Text "TestNachricht" an das Script übergeben und in der Variable $1 im Script zur Verfügung gestellt Du müsstest nun -wenn der Telegram-Befehl im Script korrekt ist- per Telegram eine Nachricht mit dem Inhalt "TestNachricht" erhalten.

Nun kannst Du das gleiche mit Verwendung der Service-Unit testen. Starte dazu

Code: Alles auswählen

systemctl start instanzen-reporter@TestNachricht.service

Hierbei wird der Instanzname TestNachricht (zusätzlich auch) in der Variable %I zur Verfügung gestellt. Und das ExecStart-Statement in der Service-Unit macht das gleiche, was Du zuvor manuell gemacht hast, es verwendet hier den an die Unit übergebenen und in %I enthalten Text "TestNachricht" . Also muss auch jetzt der Text "TestNachricht" als Telegram-Message ankommen. Wenn eins von beiden nicht geht, hast Du weitere Fehler eingebaut, wie das zuerst vergessene @. Eigentlich ist das total einfach... man muss nur sehr sorgfältig und fehlerfrei arbeiten... rein von der Sache ist das Anfängerschule....

Wenn das erste (das Script) schon nicht funktioniert bzw. nicht ordentlich sendet, brauchst Du mit dem zweiten Test gar nicht erst anfangen, dann ist das Script falsch. Das Script muss immer senden können, manuell gestartet oder nach einem Kill-Event eines überwachten Prozesses... das muss dem Script egal sein. Und wenns manuell nicht geht, geht es auch nicht aus der Überwachung. Und Du muss das in Deiner Betrachtung trennen: Die Überwachung ist eine Baustelle, das Senden eine andere. Beides muss jeweils auch ohne das andere funktionieren. Wenn beides funktioniert, funktioniert zwangsläufig auch das OnFailure-Statement in den zu überwachenden Units.... aber wie gesagt: dort ohne das %I

Ich habe es hier probiert, ging natürlich wieder nicht

Code: Alles auswählen

OnFailure=instanzen-reporter@homebridge-test.service %I

oder hier

Code: Alles auswählen

OnFailure=instanzen-reporter@homebridge-test%I.service

Das ist falsch, bitte nicht solche Experimente durchführen, wenn Du gar nicht weisst, was das für Auswirkungen hat. Bitte wieder so einrichten, wie ich das beschrieben habe, also an dieser Stelle kein %I.

[Nastra]

Code: Alles auswählen

/usr/local/bin/instanzen-reporter TestNachricht

Code: Alles auswählen

sudo /usr/local/bin/instanzen-reporter TestNachricht

Funktionieren beide, ich erhalte jeweils eine Nachricht. Aber nicht mit dem Inhalt TestNachricht.

Das hier wird ausgegeben weiterhin:

Code: Alles auswählen

$1 Instanz ausgefallen

Bin gerade alles nochmal durchgegangen, sehe aber ansonsten keine Abweichung zu dem was du vorgegeben hast. Hier meine Aktuellen Einstellungen. Vielleicht siehst du ja noch einen Fehler?

Code: Alles auswählen

#!/bin/bash

echo "Send Message $1 exited" | systemd-cat -t "$(basename $0)" -p "info"

sudo -u pi ntfy -b telegram send '$1 Instanz ausgefallen'

exit 0

Code: Alles auswählen

[Unit]
Description=instanzen-reporter@.service

[Service]
Type=oneshot
RemainAfterExit=no

ExecStart=/usr/local/bin/instanzen-reporter %I

[Install]
WantedBy=multi-user.target

Code: Alles auswählen

[Unit]
Description=homebridge-test.service
After=syslog.target network-online.target
OnFailure=instanzen-reporter@homebridge-test.service 

[Service]
Type=simple
User=root
EnvironmentFile=/etc/default/homebridge-test
ExecStart=/usr/bin/homebridge $HOMEBRIDGE_OPTS
Restart=on-failure
RestartSec=10
KillMode=process
ExecStartPre= 

[Install]
WantedBy=multi-user.target

Das ist falsch, bitte nicht solche Experimente durchführen, wenn Du gar nicht weisst, was das für Auswirkungen hat. Bitte wieder so einrichten, wie ich das beschrieben, also an dieser Stelle kein %I.

Ein paar Try and Error Übungen Ab und zu kann es ja auch klappen

[TomL]

Bin gerade alles nochmal durchgegangen, sehe aber ansonsten keine Abweichung zu dem was du vorgegeben hast. Hier meine Aktuellen Einstellungen. Vielleicht siehst du ja noch einen Fehler?

Code: Alles auswählen

echo "Send Message $1 exited" | systemd-cat -t "$(basename $0)" -p "info"
sudo -u pi ntfy -b telegram send '$1 Instanz ausgefallen'

Dann liegt der Fehler allein im Script... ich sehe auf Anhieb schon mal einen ... und zwar "sudo"... das ist hier definitiv überflüssig.
Das Script tut zwei Dinge, es legt einen Journal-Eintrag an und es sendet eine Nachricht... beides tut es mit der gleichen Nachricht in $1.

Schau mal nach, was im Log steht.. wenn die Nachricht da korrekt ist, ist schlichtweg der Sendebefehl falsch.

Code: Alles auswählen

journalctl -b | grep "Send Message"

Wenn Du in einem Root-Terminal diesen Befehl absetzt, muss es auch manuell funktionieren (wie gesagt OHNE sudo):

Code: Alles auswählen

ntfy -b telegram send 'TestNachricht Instanz ausgefallen'

Ich würde zusätzlich auch den ntf-Befehl mit vollständigem Pfad versehen:

Code: Alles auswählen

which ntfy

Und ich erwähne das noch mal... auf einem solchen System mit Zugang von außen solltest Du tunlichst den User "pi" entfernen, idealerweise auch die Gruppe "sudo" leeren, am Besten sogar ganz "sudo" deinstallieren und für "root" ein eigenes sehr anspruchsvolles Password vergeben.

[Nastra]

Code: Alles auswählen

Mär 02 10:33:13 HomeKitServer instanzen-reporter[29799]: Send Message TestNachricht exited
Mär 02 10:34:24 HomeKitServer instanzen-reporter[30666]: Send Message TestNachricht exited
Mär 02 10:43:53 HomeKitServer instanzen-reporter[5265]: Send Message TestNachricht exited

Sieht eigentlich gut aus oder?

Wenn Du in einem Root-Terminal diesen Befehl absetzt, muss es auch manuell funktionieren:
CODE: ALLES AUSWÄHLEN
ntfy -b telegram send 'TestNachricht Instanz ausgefallen'

Funktioniert, kommt genau so an.

ntfy -b telegram send 'TestNachricht Instanz ausgefallen'
Ich würde jeden den ntf-Befehl mit vollständigem Pfad versehen:
CODE: ALLES AUSWÄHLEN
which ntf

Erledigt, klappt auch noch

Und ich erwähne das noch mal... auf einem solchen System mit Zugang von außen solltest Du tunlichst den User "pi" entfernen, idealerweise auch die Gruppe "sudo" leeren, am Besten sogar ganz "sudo" deinstallieren und für "root" ein eigenes sehr anspruchsvolles Password vergeben.

Danke für den Hinweis. Wenn alles funktioniert werde ich mich mit dem Thema mal beschäftigen.

[TomL]

Also... das Fazit... die Units sind ok... die Nachricht kommt einfandfrei im Log an. Genauso müsste jetzt auch die Nachricht von den ausgefallenen Services im Log ankommen. Das heisst, an diesem Punkt muss man nichts mehr ändern. Wenn es jetzt noch Probleme beim Senden gibt, was nicht am Inhalt von $1 innerhalb des Scripts liegen kann, weil diese Nachricht in $1 ja sauber im Log ankommt, dann liegt es alleine am Sende-Befehl. Das muss man nun ausklamüsern, wie das geht.
Der Sendevorgang muss aber gleichermaßen direkt im Terminal funktionieren, mit exakt dem gleichen Statement, wie es im Script eingetragen ist. Wenn das eine nicht geht, geht das zweite auch nicht. Und wie gesagt ohne "sudo"!

Oh... hoffentlich kein Missverständnis.... Du solltest die Rückgabe aus

Code: Alles auswählen

which ntfy

vollständig so in das Script übernehmen... also nicht nur "ntfy", sondern einschließlich des ganzen Pfades.

[Nastra]

Habe den Fehler gefunden. So funktioniert der Befehl und ich bekomme den Namen der Instanz mit ausgegeben:

Code: Alles auswählen

/usr/local/bin/ntfy -b telegram send $1' Achtung'

Ergebnis:

Code: Alles auswählen

homebridge/test Achtung

Oh... hoffentlich kein Missverständnis.... Du solltest die Rückgabe aus
CODE: ALLES AUSWÄHLEN
which ntfy

Habe ich auch so verstanden

Cool und nochmal besten danke bis hier hin

Jetzt weiss ich wie es funktioniert, habe aber noch eine Frage an dich bezüglich der nicht Homebridge Service die ich gerne Überwachen möchte. Wir haben ja in der Homebridge Unit OnFailure genutzt um dem Instanzen.reporter mitzuteilen das er tätig wird und das Skript auslöst.

Kann ich mit dieser Lösung auch individuelle Dinge überwachen wie ein Backup ist abgeschlossen welches durch einen eigenen Service angesteuert wird? Denke OnFailure wird da nicht klappen

[TomL]

Kann ich mit dieser Lösung auch individuelle Dinge überwachen wie ein Backup ist abgeschlossen welches durch einen eigenen Service angesteuert wird? Denke OnFailure wird da nicht klappen

Ja, sicher... ich weiss nur nicht, ob das sinnvoll ist. Statt

Code: Alles auswählen

systemctl start instanzen-reporter@BackupFertig.service

kann man den ntfy-Befehl auch direkt im Backup-Job eintragen.

Wichtig ist nur eines noch... beschränke Dich unbedingt darauf, nur EinWort-Instanzen zu nehmen... keine Blanks, keine Sonderzeichen... das ist eigentlich nicht als Nachrichtensystem gedacht, sondern um Units instantiiert starten zu können... und instanzen sollten einen eindeutigen einfachen Namen haben, der nicht zur Konflikten mit systemd führt.... was ich bei Sonderzeichen nicht für ausgeschlossen halte.

Die "Nachricht"

Code: Alles auswählen

homebridge/test

solltest Du besser so gestalten

Code: Alles auswählen

homebridge_test

und unbedingt auf / verzichten.

[Nastra]

Im Backup-Job meinst du die Unit vom Backup Service, also auch bei OnFailure?

Ich weiß garnicht wo das / in der Nachricht her kommt. Der Befehl ist so definiert wie in dem Beispiel ein post über dir mit Achtung.

Edit:
Ok, fehler auch gefunden er erkennt in der OnFailure Zeile das - bei homebridge-test als /.

Habe es jetzt zum Testen auf einen _ geändert dann kommt es so an:

Code: Alles auswählen

homebridge_test Achtung

[TomL]

Im Backup-Job meinst du die Unit vom Backup Service, also auch bei OnFailure?

Keine Ahnung... weiss ja nicht, wie Du das Backup handhabst...ob das ein Script ist, oder ein Programm... ob das manuell gestartet wird, via Cron, via service-unit und systemd-timer. Wenn das nur ein Script ist, kann man den ntfy ja auch direkt ins Script einbauen... also das würde ich eher nicht über OnFailure lösen... sondern besser über Mail-Benachrichtigungen.

Ich habe heute morgen von meinem Server im Keller eine Mail bekommen, mit der ich informiert werde, dass er die Homedirs gesichert und nach extern übertragen hat:

Code: Alles auswählen

xtbak - SIK SSD-Home (raspi):
02.03.2018-05:00:12: Create Tarfile started
02.03.2018-05:06:30: Create Tarfile done (RC=0)
02.03.2018-05:06:30: md5checksum started
02.03.2018-05:07:00: md5checksum done (RC=0)
02.03.2018-05:07:00: Test Tarfile started
02.03.2018-05:07:52: Test Tarfile done (RC=0)
02.03.2018-05:08:02: Encrypt Tarfile started
02.03.2018-05:09:48: Encrypt Tarfile done (RC=0)
02.03.2018-05:09:49: FTP-Send encrypted File started
02.03.2018-05:24:49: FTP-Send encrypted File done (RC=0)

Sowas krieg ich 12 mal monatlich plus täglich das Ergebnis des rsync-Laufes. Wenn es Dich interessiert, kann ich Dir nen Link senden, wie ich meine Backups durchführe.... ist aber ziemlich umfangreich beschrieben.... nicht nur das wie, sondern auch das warum und was.

[Nastra]

Das Backup erstelle ich über einen timer.service der einen backup.service anstößt und anschließend ein Skript ausführt was alle Homebridge Service abschaltet und ein vollständiges Image über dd erstellt.

Das funktioniert seit längerem sehr gut. Bei mir sind es nur 8GB auf einem USB 3 Stick die gesichert werden müssen da ich das OS nicht als Produktionssystem nutze sondern ausschließlich als Homebridge Server.

Ich denke ich bleibe erstmal bei dieser Variante, trotzdem vielen Dank für das Angebot.

[NAB]

Ich habe das Skript testweise mit der neuen Zeile ausgestattet

Code: Alles auswählen

#!/bin/bash                                                                                                  
journalctl -u homebridge-test -u homebridge-hue -f --since "now" |                                                                     
grep --line-buffered -e "exit" -e "exited"                                                                       
sudo -u pi xargs -L1 -t -I '$' ntfy -b telegram send 'Achtung - ''$'

diese funktioniert auch gem. Status

Gut. Also die erste Zeile funktioniert

und er findet die Suchbegriffe aber nicht getrennt für die einzelnen Units. Also er sucht in beiden Units nach beiden Suchbegriffen.

Das ist logisch. Das kann "grep" nicht. grep kriegt eine Zeile nach der nächsten vorgelegt und durchsucht sie nach den angegebenen Suchbegriffen. Insbesondere enthält "exited" schon das Wort "exit" also findet "exit" beide Varianten: "exit" und "exited".

Das ist genau der Punkt, an dem wir jetzt tricksen müssen. Und das ist der Punkt, an dem ich dir nur begrenzt verraten kann, wie es geht, weil ich nicht genau weiß, was für Zeilen du angezeigt bekommen möchtest und welche nicht. Mir ist schon in deinem Beispiel nicht klar, bei welchen Zeilen du nur ein "exited" sehen möchtest und bei welchen ein "exit". Die einfachste Möglichkeit um zu verhindern, dass "exit" und "exited" verwechselt werden ist natürlich, einfach das Zeichen anzugeben, das nach "exit" kommen soll, also zum Beispiel "exit " (mit einem Leerzeichen dahinter). Sowas kommt in deinem Beispiel aber gar nicht vor.

"grep" kennt ein paar geheime Zeichen, zum Beispiel den Punkt . und den Stern *

Der Punkt steht stellvertretend für EIN beliebiges Zeichen. Der Stern bedeutet, dass das Zeichen davor sich beliebig oft wiederholen darf. Somit steht .* für beliebig viele beliebige Zeichen. Ein paar einfache Beispiele:

Code: Alles auswählen

$ echo -e "eins\nzwei\ndrei" | grep --line-buffered -e "eins" -e "drei"
eins
drei
$ echo -e "eins\nzwei\ndrei" | grep --line-buffered -e "eins" -e "d.ei"
eins
drei
$ echo -e "eins\nzwei\ndrei" | grep --line-buffered -e "eins" -e "d.*ei"
eins
drei
$ echo -e "eins\nzwei\ndrei" | grep --line-buffered -e "eins" -e "d.*i"
eins
drei

Das sind jetzt ziemlich langweilige Beispiele ... wie kannst du die bei dir umsetzen? Zum Beispiel so:

Code: Alles auswählen

grep --line-buffered -e "homebridge-hue.*start" -e "homebridge-test.*exited"

Das zeigt dir von "homebridge-hue" nur noch Zeilen an, die "start" enthalten und von "homebridge-test" nur noch Zeilen, die "exit" enthalten (hoffentlich, ich mach hier ja mal wieder Trockenübungen;)

Du musst da ein paar graue Zellen reininvestieren um möglichst präzise die Zeilen rauszufiltern, die du haben willst ohne dass die grep-Zeile zu unübersichtlich wird. Das Beispiel von eben ließe sich vermutlich verkürzen auf:

Code: Alles auswählen

grep --line-buffered -e "hue.*start" -e "test.*exited"

Es wird aber keine Pushnachricht mehr erzeugt? Ich gehe mal davon aus das jetzt

Code: Alles auswählen

sudo -u pi xargs -L1 -t -I '$' ntfy -b telegram send 'Achtung - ''$'

nicht mehr passt und geändert werden muss?

Nein, daran liegt's nicht.
Wie schon erklärt, schweißt du deine drei Befehle mit dem senkrechten Strich zusammen:
journalctl | grep | xargs
Du hast den Strich hinter grep jetzt weggelassen. xargs kriegt also gar keine Eingaben mehr und guckt in die leere Röhre.

Dann liegt der Fehler allein im Script... ich sehe auf Anhieb schon mal einen ... und zwar "sudo"... das ist hier definitiv überflüssig.

Das ist nicht überflüssig sondern sorgt dafür, dass er ein komisches Pythonscript aus Drittquellen nicht als root ausführt. Was du da empfiehlst ist fahrlässig.

[TomL]

Was du da empfiehlst ist fahrlässig.

Das sagt der systemd-Gegner.... ... systemd-Services werden automatisch mit root-Rechten ausgeführt... und meine Lösung ist eine reine systemd-Lösung. "sudo" ist an der Stelle falsch.

[NAB]

Das sagt der systemd-Gegner.... ... systemd-Services werden automatisch mit root-Rechten ausgeführt... und meine Lösung ist eine reine systemd-Lösung. "sudo" ist an der Stelle falsch.

Geil ... drei Fehler in zwei Zeilen ... Respekt! *g*

[TomL]

Geil ... drei Fehler in zwei Zeilen ... Respekt! *g*

Ok... bitte helfe mir... ich sehe die nicht.... wo?

[Nastra]

Guten Morgen,

@NAB danke für die Erklärung

Code: Alles auswählen

Das ist logisch. Das kann "grep" nicht. grep kriegt eine Zeile nach der nächsten vorgelegt und durchsucht sie nach den angegebenen Suchbegriffen. Insbesondere enthält "exited" schon das Wort "exit" also findet "exit" beide Varianten: "exit" und "exited". 

War ein doofes Beispiel kommt so auch nicht vor in der Realität. Sry

Habe die neue Zeile getestet, funktioniert! Super!

Code: Alles auswählen

pi@HomeKitServer:~ $ sudo systemctl status reporter-homebridge.service
● reporter-homebridge.service
   Loaded: loaded (/etc/systemd/system/reporter-homebridge.service; enabled; ven
   Active: active (running) since Sat 2018-03-03 07:22:19 CET; 1s ago
 Main PID: 4019 (reporter-homebr)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/reporter-homebridge.service
           ├─4019 /bin/bash /usr/local/bin/reporter-homebridge.sh
           ├─4020 journalctl -u homebridge-test -u homebridge-hue -f --since now
           ├─4021 grep --line-buffered -e homebridge-hue.*FAILURE -e homebridge-
           ├─4022 sudo -u pi xargs -L1 -t -I $ ntfy -b telegram send Achtung - $
           └─4030 xargs -L1 -t -I $ ntfy -b telegram send Achtung - $

Code: Alles auswählen

#!/bin/bash                                                                                                  

journalctl -u homebridge-test -u homebridge-hue -f --since "now"  | 
grep --line-buffered -e "homebridge-hue.*FAILURE" -e "homebridge-test.*exited"  | 
sudo -u pi xargs -L1 -t -I '$' ntfy -b telegram send 'Achtung - ''$'

Jetzt ist nur noch die Frage wie man verschiedene Nachrichten versenden kann zu den aufgetreten Ereignissen?

[scientific]

Ohne jetzt all die schönen Lösungen im Detail durchgesehen zu haben, möchte ich auch noch etwas Senf auf diesen Teller dazudrücken.

Systemd hat eine Option in der Unit-Section:

Code: Alles auswählen

OnFailure=status-email-root@%n.service

Dazu gibt es dann eine weiter unit die heißt:

Code: Alles auswählen

$ cat /etc/systemd/system/status-email-root@.service 
[Unit]
#Description=status email for %I to root 
Description=status email for %i to root 

[Service]
Type=simple
ExecStart=/etc/systemd/scripts/systemd-email root@localhost %i
#User=nobody
Group=systemd-journal

Und diese Unit ruft dann das Skript:

Code: Alles auswählen

$ cat /etc/systemd/scripts/systemd-email 
#!/bin/bash

/usr/sbin/sendmail -t <<ERRMAIL
To: $1
From: systemd <root@$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status -a --full "$2")
ERRMAIL

auf.

Die Magie dahinter ist einfach. Jede Unit, welche "OnFailure=status-email-root@%n.service" hat ruft bei im Failure-Falle die Unit status-email-root@%n.service auf. Wobei systemd %n mit dem gesamten Unit-Name der fehlgeschlagenen Unit ersetzt.
Bei mir wäre das z.B. für die Unit mkbackup@daily.service (falls mein Backup fehlschlägt) status-email-root@mkbackup@daily.service.service.
Der "Übergabeparameter" also der Instanzenname für status-email-root ist dann der Name der fehlgeschlagenen Unit mkbackup@daily.service.

Das Skript status-emai-root@.service führt dann das Skript systemd-email mit den Übergabeparametern "root@localhost" und "mkbackup@daily.service" aus.
Dieses Skript erzeugt in meinem Falle ein Email mit dem Absender "root@hostname" an root@localhost (Übergabeparameter!!!) und im Email wird ein Status-Dump der fehlgeschlagenen Unit verpackt.

In dieses Skript kannst du Statt dem aufbau eines Emails auch die Telegram-Notification einbauen. Der Rest bleibt gleich.
Wenn du verschiedene Empfänger je nach überwachter Unit haben willst, benötigst du "nur" für jeden Empfänger eine Unit "status-email-root@.service" status-email-user1@.service"... Und dem Skript in der Unit gibst du dann den jeweiligen User wie die Unit heißt.
Und in die zu überwachenden Units baust du dann nur die Zeile "OnFailure=status-email-root@%n.service" ein. Du kannst auch mehrere Empfänger für eine Unit angeben mit

Code: Alles auswählen

OnFailure=status-email-root@%n.service status-email-user1@%n.service

Damit du updatefest diese Anpassungen in System-Units einbaust, verwendest du für jede Unit ein sogenanntes Drop-In.

Dazu legst du in /etc/systemd/system für jede zu überwachende Unit ein Verzeichnis an, das sieht so aus:

Code: Alles auswählen

/etc/systemd/system/cups.serivce.d/

Also der Unit-Name mit einem ".d" angehängt.

Für die Vereinfachung der Verwaltung legst du in /etc/systemd/system dann ein File mit der Endung ".conf" für jeden zu benachrichtigenden User als Drop-In an. Z.b. für root und für User1 sieht das dann so aus:

Code: Alles auswählen

cat /etc/systemd/system/ntfy-root.conf
[Service]
OnFailure=status-email-root@%n.service

Code: Alles auswählen

cat /etc/systemd/system/ntfy-user1.conf
[Service]
OnFailure=status-email-user1@%n.conf

Um cups.service mkbackup@.service (alle Instanzen) oder nur von z.B. der wöchentlichen Sicherung mkbackup@weekly.service zu überwachen musst du eben die genannten Verzeichnisse mit dem Unit-Namen und angehängtem .d erzeugen:

Code: Alles auswählen

mkdir /etc/systemd/system/cups.service.d /etc/systemd/system/mkbackup@.service

erzeugen und darin dann die obigen Drop-Ins reinverlinken:

Code: Alles auswählen

ln -s ../ntfy-root.conf /etc/systemd/system/cups.service.d/ntfy-root.conf
ln -s ../ntfy-user1.conf /etc/systemd/system/mkbackup@.service.d/ntfy-user1.conf

Oder wenn du nur das wöchentliche Backup überwachen willst, dann

Code: Alles auswählen

ln -s ../ntfy-user1.conf /etc/systemd/system/mkbackup@weekly.service.d/ntfy-user1.conf

Danach eine

Code: Alles auswählen

systemctl daemon-reload

und schon sollten die Überwachungen aktiv sein.

Die Benachrichtigung kommt dann nur, wenn ein Dienst mit einem Errorcode > 0 (also ungeplantes Fehlschlagen) beendet wird. Wird ein Service ordnungsgemäß beendet (systemctl stop, oder der Dienst kommt regulär zum Ende), gibts keine Benachrichtigung.

Ich hoffe, du kannst was damit anfangen.

lg scientific

[scientific]

Eine generelle Überprüfung und Benachrichtigung über fehlgeschlagene Dienste könnte z.B. so aussehen:

Du hast eine Unit

Code: Alles auswählen

cat /etc/systemd/system/check-failed-services.service
[Unit]
Description=Peridoic check for failed units
OnFailure=status-email-root@%n.service
[Service]
ExecStart=/bin/sh -c "E=$(systemctl --failed --no-legend|wc -l); exit $E"

Dazu brauchst du dann noch einen Timer:

Code: Alles auswählen

cat /etc/systemd/systemd/check-failed-services.timer
[Unit]
Description=peridoc check for failed services

[Timer]
OnCalendar=Mon *-*-* 12:00:00
Persistent=true

[Install]
WantedBy=basic.target

Dann den Timer enablen mit

Code: Alles auswählen

systemctl enable check-failed-services.service

Und überprüfen, ob er auch tatsächlich aktiv ist mit

Code: Alles auswählen

systemctl list-timers

In diesem Fall wird die Unit jeden Montag um 12:00:00 ausgeführt.

Einen Schönheitsfehler hat dieser Schnellschuß. Die Prüfungsunit failed selbst und erhöht damit den Zähler um eins. Was aber nichts ausmacht, denn die Unit failed nur dann, wenn es bereits failed Units gibt.
Und die Benachrichtigung zeigt nur an, dass die check-unit fehlgeschlagen ist. Um die Benachrichtigung schöner zu machen, müsstest du eine eigen status-email-.... Unit und ein eigenes Skript bauen, welches die Ausgabe von systemctl --failed in die Benachrichtigung einbaut.

Wenn du die Units überprüft und wieder zum Laufen gebracht hast, kannst du die failed units mit

Code: Alles auswählen

systemctl reset-failed

wieder zurücksetzen.

lg scientific

[Nastra]

@ scientific

Bin unterwegs und habe es gerade auf dem Handy überflogen. Muss es mir später mal in Ruhe durchlesen. Aber schonmal Vielen Dank für die ausführliche Beschreibung deiner Lösungsmöglichkeit

Ich merke hier sind viele Leute die sich sehr gut auskennen und die Unterstützung ist auch wirklich erste Sahne

[TomL]

@ scientific