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

[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

[scientific]

Gern.

Hab grad noch die allgemeine Überprüfung auf failed services vereinfacht!
Ich spar mir eine Variable und führ direkt

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 "exit $(systemctl --failed --no-legend|wc -l)"

aus.

[NAB]

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?

Ja, was meinst du denn damit? Du müsstest doch jetzt schon verschiedene Nachrichten bekommen, mit der jeweils individuellen Zeile aus journalctl? Oder klappt das nicht?

Eigentlich macht das Script jetzt alles, was du am Anfang wolltest. Du kannst unterschiedliche Dienste überwachen und kriegst unterscheidbare Nachrichten, welcher Dienst ausgefallen ist. Und das in popeligen drei Zeilen. Und du kannst sogar sinnvolle Änderungen daran durchführen.

Dazwischen wolltest du auch noch auf die Nachricht "USB-Stick" überwachen ... das sieht nicht mehr nach "Dienst ausgefallen" aus sondern nach was anderem, ginge aber auch.

Wir können jetzt anfangen, die Zeilen noch zurechtzuschneiden oder einzelne Textpassagen zu ersetzen oder mit IF THEN wirklich individuell auf einzelne Ereignisse zu reagieren. Dazu braucht's aber ein wenig "Konzept" damit eine sinnvolle Programmlogik daraus wird. Und noch wichtiger - du musst die Geschichte auch verstehen, damit du sinnvoll eingreifen und anpassen kannst.

Also ... was soll es denn werden?

Und guck dir bitte mal an, was scientific da zu Drop-Ins geschrieben hast. Das gefällt mir nämlich gar nicht, dass du in funktionierenden und womöglich vom System vorgegebenen Unit-Dateien herumschreibst. Da reicht ein kleiner Fehler und die Unit startet nicht mehr, und wenn's was Wichtiges war, hast du plötzlich ein nicht-startendes System und musst das erst mal reparieren. Von der Update-Problematik ganz zu schweigen.

[Nastra]

Hey NAB,

du hast Recht die Funktionalität so wie sie jetzt ist macht genau das was ich mir ursprünglich vorgestellt habe. Hatte voller Euphorie noch den Skript Aufbau von breakthewall etwas im Hinterkopf (was ja garnicht lief in meinem Szenario) bei dem man auch den Suchbegriff mit der Individuellen Nachricht verknüpfen konnte.

Ich denke das ich dass nicht unbedingt brauche (das wäre mehr nice to have für andere Szenarien) und bin mit den jetzigen Lösung (Skript & systemd) völlig zufrieden, das ist viel mehr als ich eigentlich erwartet habe

Ich möchte mich nochmal für die Geduld und Ausdauer besonders bei dir und TomL an dieser Stelle bedanken.

@ scientific dir auch nochmal danke für die Mühe, ich denke ich werde aber bei einer der zwei Möglichkeiten bleiben die ich jetzt zur Verfügung habe, um die ganze Sache nicht für mich zu kompliziert zu machen. Aber der ein oder andere der diesen Thread hier zukünftig liest wird bestimmt davon noch profitieren

Schönes Wochenende euch allen noch !

Gruß Nastra

[scientific]

Wenn du halt nicht mit den Drop-Ins arbeirest, sondern direkt die Units in /lib/systemd/system bearbeitest, sind deine Änderungen beim Nächsten Update Geschichte, und du weißt gar nicht, warums plötzlich nicht mehr funktioniert...

[Nastra]

Nächsten Update Geschichte

Die Service sind doch alle selber manuell angelegt egal ob ich jetzt Lösung von NAB oder TomL benutze, welcher Art Update würde diese Units verändern im nachhinein ?

[scientific]

Ahso. Ja. Stimmt. Sorry.

[NAB]

Hatte voller Euphorie noch den Skript Aufbau von breakthewall etwas im Hinterkopf (was ja garnicht lief in meinem Szenario) bei dem man auch den Suchbegriff mit der Individuellen Nachricht verknüpfen konnte.

Ich denke das ich dass nicht unbedingt brauche (das wäre mehr nice to have für andere Szenarien)

Hmm ... den Suchbegriff mit der Individuellen Nachricht verknüpfen? Ich hab mir das Script von breakthewall noch mal angeguckt ... auch der versteckt die Suchbegriffe irgendwo in der Programmlogik. Aber wenigstens stehen die Nachrichten groß oben drüber.

Ich hab noch mal etwas am Script herumgebastelt. Ich stecke die Ausgabe von journalctl jetzt in eine ewige While-Schleife. Die While-Schleife bekommt jede einzelne Zeile vorgelegt, die journalctl ausspuckt. Die Zeile steckt sinniger Weise in der Variablen $zeile. Die While-Schleife prüft in (bisher drei) IF THEN Konstrukten per grep auf die (bisher drei) Suchbegriffe und bei Erfolg tut sie was. Nur was?

Ich habe zwei Varianten geschrieben. Ich kann mich nicht entscheiden, welche Version ich dir zeigen soll, also zeig ich dir beide: Variante 1:

Code: Alles auswählen

#!/bin/bash

suchbegriff1="Failed"
nachricht1="Auf Homeserver ist was schiefgelaufen: "

suchbegriff2="Started.*homebridge-test"
nachricht2="homebridge-test wurde gestartet."

suchbegriff3="USB-Stick"
nachricht3="Jemand hat USB-Stick gesagt! "

journalctl -u homebridge-test -u homebridge-hue -u backup -f --since "now"  | \
    while read -r zeile; do
	
        if grep --quiet "$suchbegriff1" <<< "$zeile"; then
           echo sudo -u pi ntfy -b telegram send "$nachricht1$zeile"
	fi

        if grep --quiet "$suchbegriff2" <<< "$zeile" ; then
           echo sudo -u pi ntfy -b telegram send "$nachricht2"
	fi

        if grep --quiet "$suchbegriff3" <<< "$zeile" ; then 
	   echo sudo -u pi ntfy -b telegram send "$nachricht3"
	fi
		
    done

Und Variante 2:

Code: Alles auswählen

#!/bin/bash

suchbegriff1="Failed"
nachricht1="Auf Homeserver ist was schiefgelaufen: "

suchbegriff2="Started.*homebridge-test"
nachricht2="homebridge-test wurde gestartet."

suchbegriff3="USB-Stick"
nachricht3="Jemand hat USB-Stick gesagt! "

journalctl -u homebridge-test -u homebridge-hue -u backup -f --since "now"  | \
    while read -r zeile; do
	
        if grep --quiet "$suchbegriff1" <<< "$zeile"; then
	   nachricht=$nachricht1$zeile
	fi

        if grep --quiet "$suchbegriff2" <<< "$zeile" ; then
	   nachricht=$nachricht2
	fi

        if grep --quiet "$suchbegriff3" <<< "$zeile" ; then 
	   nachricht=$nachricht3
	fi

        if [ -n "$nachricht" ]; then
	   echo sudo -u pi ntfy -b telegram send "$nachricht"
	   nachricht="" 
	fi    
		
    done

Die erste Variante schickt dir bei jedem Treffer auf einen Suchbegriff sofort eine Nachricht. Da könntest du zum Beispiel auch eine andere Aktion eintragen als das Versenden einer Nachricht.

Die zweite Variante befüllt bei jedem Treffer auf einen Suchbegriff nur die Variable "nachricht" (ohne Zahl dahinter). Und ganz am Ende guckt sie nach, ob in "nachricht" was drin ist (das vierte IF-THEN Konstrukt) und wenn ja, schickt sie dir diese einzelne Nachricht.

Beide Scripte schicken dir übrigens nicht wirklich Nachrichten. Sie drucken dir mit "echo" nur aus, was sie tun würden. Starte die erst mal so auf der Konsole und schau, was du damit anfangen kannst. Wenn es gut aussieht, kannst du das "echo" im "echo sudo" entfernen.

Und wenn du genau hinschaust ... beim ersten IF-THEN-Konstrukt habe ich etwas anders gemacht. Da hänge ich an nachricht1 noch $zeile ran. Dadurch wird dir die gesamte Zeile aus journalctl zur Nachricht hinzugefügt. Kannst du natürlich auch anders machen.

Die Service sind doch alle selber manuell angelegt egal ob ich jetzt Lösung von NAB oder TomL benutze, welcher Art Update würde diese Units verändern im nachhinein ?

Das können wir doch nicht wissen, welche Units du alle überwachen willst. Und du selber denkst ja auch über "andere Szenarien" nach

[scientific]

Also ein Skript, welches das Journal parst, brauch doch viel zu viel Ressourcen. Zumal es doch bei systemd einen Mechanismus gibt, der auf fehlschlagende Services direkt reagiert.

Was interessiert mich ein journal in einer telegram-Nachricht, wenn doch der Name der Unit ausreicht, um zu wissen, welcher service ausgefallen ist. Ich muss ja sowieso auf den Rechner um zu recherchieren, was das Problem ist.

[NAB]

Eh ... viel zu viel Ressourcen? Hat dein PC sehr lange gebraucht, um all den Text dieser Webseite zu parsen?

Dass euer Ansatz auf "failed" reagieren kann, haben wir doch nun schon durchgekaut. Das ist aber auch alles.

[Nastra]

Guten Morgen NAB,

habe gerade beide Variante Live getestet, was soll ich sagen, absolute Spitze, bin echt baff

Ich habe mich vorerst für Variante II entschieden, da ich bisher nur das Szenario habe eine Telegram Nachricht zu verschicken. Aber Variante I ist natürlich für maximale Flexibilität genial um eventuell andere Dinge anzustoßen. Da muss ich mir nochmal Gedanken machen was man alles schönes anstellen kann statt eine Nachricht zu versenden

Habe auch schon alles angepasst nach meinen Bedürfnissen und es läuft

Dankeschön!!!!

[NAB]

Ich habe mich vorerst für Variante II entschieden, da ich bisher nur das Szenario habe eine Telegram Nachricht zu verschicken. Aber Variante I ist natürlich für maximale Flexibilität genial um eventuell andere Dinge anzustoßen. Da muss ich mir nochmal Gedanken machen was man alles schönes anstellen kann statt eine Nachricht zu versenden

Ich bin mir nicht sicher, ob du das verstanden hast. Auch Variante 1 ist nicht dafür gedacht, dir drei Nachrichten auf einmal zu schicken. Den drei IF-THEN-Konstrukten wird in beiden Varianten immer die aktuelle Zeile aus journalctl vorgelegt. Wenn du Variante 1 dazu kriegst, dir drei Nachrichten zu schicken, dann hast du sehr dämliche Suchbegriffe genommen, zum Beispiel "exited", "exit" und "ex". Dann kriegst du auf "exited" wirklich drei Nachrichten.

Variante 2 würde dir in diesem Fall nur die letzte der drei Nachrichten schicken, aber dämlich wär's trotzdem

P.S.: Genehmigung zum Veröffentlichen dieser Scripte ausdrücklich erteilt, auf Anfrage des TE per PN.

[scientific]

Ich kann mir nicht helfen... Eine Lösung, in der das ganze journal regelmäßig geparst werden muss, ist keine schöne Lösung.

Wenn du eine Nachricht bei erfolgreichem Ende willst, verwende eine Zeile

Code: Alles auswählen

 ExecStarPost=/usr/local/bin/ntfy... 

.
Und beim fehlschlagen ruf mit OnFailure= einen Service auf, der dich benachrichtigt.

Damot hat du in der Sekunde eine Verständigung, was los ist. Und du sparst dir das regelmäßige Parsen des Journals.

Das Backupskript von ExecStart darf dabei nicht in den Hintergrund geforkt werden!

Lg scientific

[Nastra]

Hallo nochmal zusammen,

da ich die Tage einen alten Freund getroffen habe der mir noch ein wenig unter die Arme gegriffen hat bezüglich meines Vorhabens möchte ich euch meine entgültige Lösung natürlich hier auch nicht vorenthalten.

Als Grundlage für diese erweiterterung hat das Skript von @NAB siehe weiter oben (Variante II) gedient.

Zusammenfassung:
Mit diesem Skript ist es jetzt möglich verschieden Units /Service zu Überwachen auf bestimmte Suchbegriffe. Sollte einer dieser Suchbegriffe auftauchen wird eine Nachricht über den Telegram Messenger versendet. Die besonderheit dabei ist das bei meinem vorhaben die homebridge alle 10 Sekunden nach einem Absturz neustartet um den Dienst nach möglichkeit schnellstmöglich wieder aufzunehmen gem. Unit einstellungen onFailure.

Da ich aber nicht alle 10 Sek eine Nachricht erhalten möchte sondern nur alle 30 Min, falls man mal nicht direkt nachsehen kann oder es Nacht ist wird nun ein Zeitstempel nach erstmaligen auslösen der Nachricht hinzugefügt.
Dadurch ist es möglich das die nächste Nachricht wie hier im Beispiel mit einer Verzögerung von 30 Minuten erst wieder erneut gesendet wird.

Die systemd Lösungen waren mir schlussendlich für mein spezielles Vorhaben zu unflexibel. Trotzdem nochmal danke an alle Beteiligten!

Code: Alles auswählen

#!/bin/bash

######################## NACHRICHTEN VERZÖGERUNG ######################


letzteNachricht1=$(($(date +"%s")-1800))

letzteNachricht2=$(($(date +"%s")-1800))

letzteNachricht3=$(($(date +"%s")-1800))

letzteNachricht4=$(($(date +"%s")-1800))


######################## Überwachte Service ###########################


journalctl -u homebridge* -f --since "now"  | \
while read -r zeile; do


########################## SUCHBEGRIFFE ###############################


suchbegriff1="homebridge.*FAILURE"
nachricht1="ACHTUNG: "

suchbegriff2="communication"
nachricht2="HINWEIS: "
	
suchbegriff3="error"
nachricht3="HINWEIS: "

suchbegriff4="UUID"
nachricht4="HINWEIS: "


########################## NACHRICHTEN ###############################


if grep --quiet "$suchbegriff1" <<< "$zeile "  && [ $((letzteNachricht1+1800)) -lt $(date +"%s ") ] ; then
nachricht=$nachricht1$zeile
letzteNachricht1=$(date +"%s ")
fi


if grep --quiet "$suchbegriff2" <<< "$zeile "  && [ $((letzteNachricht2+1800)) -lt $(date +"%s ") ] ; then
nachricht=$nachricht2$zeile
letzteNachricht2=$(date +"%s ")
fi


if grep --quiet "$suchbegriff3" <<< "$zeile "  && [ $((letzteNachricht3+1800)) -lt $(date +"%s ") ] ; then
nachricht=$nachricht3$zeile
letzteNachricht3=$(date +"%s ")
fi


if grep --quiet "$suchbegriff4" <<< "$zeile "  && [ $((letzteNachricht4+1800)) -lt $(date +"%s ") ] ; then
nachricht=$nachricht4$zeile
letzteNachricht3=$(date +"%s ")
fi


################## VERSAND ÜBER NTFY AN TELEGRAM #####################


if [ -n "$nachricht" ]; then
sudo -u pi ntfy -b telegram send "$nachricht"
nachricht=""
fi    
		
done

Gruß Nastra

[NAB]

Man man man ... das ist ja ganz schön fett geworden im Vergleich zu den drei Zeilen am Anfang

Ich würde die "1800" auch noch zu einer Variablen machen:

Code: Alles auswählen

######################## NACHRICHTEN VERZÖGERUNG ######################
flutschutz1=1800
letzteNachricht1=$(($(date +"%s")-$flutschutz1))

Das IF-THEN-Konstrukt sähe dann so aus:

Code: Alles auswählen

if grep --quiet "$suchbegriff1" <<< "$zeile"  && [ $((letzteNachricht1+$flutschutz1)) -lt $(date +"%s ") ] ; then
    nachricht=$nachricht1$zeile
    letzteNachricht1=$(date +"%s ")
fi

Vorteil: Du musst die "1800" nicht in jedem IF-THEN-Konstrukt per Hand nachbesser, wenn du sie ändern willst.

Außerdem könnte man:

Code: Alles auswählen

jetzt=$(date +"%s")

if grep --quiet "$suchbegriff1" <<< "$zeile "  && [ $((letzteNachricht1+$flutschutz1)) -lt $jetzt ] ; then
    nachricht=$nachricht1$zeile
    letzteNachricht1=$jetzt
fi

Vorteil: das "date" wird nur einmal pro While-Schleifen-Durchgang aufgerufen (dafür aber jedes mal). Achtung: Das jetzt=$(date +"%s") muss da auch nur ein mal stehen, vor dem ersten IF-THEN.

Außerdem würde ich "SUCHBEGRIFFE" wieder vor die While-Schleife ziehen ... die Variablen werden jetzt nämlich sinnloser Weise bei jedem Durchgang neu definiert.

Und die IF-THEN-Konstrukte sind jetzt etwas unübersichtlich geworden, aber was "benutzerfreundlicheres" fällt mir auch nicht ein. Man könnte sie auseinanderziehen, das macht's aber länger und vermutlich trotzdem nicht besser. Mal schauen, ob da jemand noch eine elegantere Idee hat ...

P.S.: Und ich würd's "NACHRICHTEN BEGRENZUNG" nennen ... verzögern tust du da nämlich eigentlich nichts. Ich hab erst mal dumm geguckt, was das eigentlich soll, bis ich mir den Sinn erschlossen habe.

[scientific]

Postest du deine Unit bitte auch noch einmal?