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

[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?

[Nastra]

Hier noch die Unit:

Code: Alles auswählen

[Unit]
Description=reporter.service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/reporter.sh
Restart=always
SyslogIdentifier=reporter.service

[Install]
WantedBy=multi-user.target

@NAB

danke für die Verbesserungsvorschläge ich schaue Sie mir morgen in Ruhe an und teste es mal aus.
Melde mich dann wieder

[NAB]

Restart=always? Also ... theoretisch ist das Script natürlich fehlerfrei und der Fall tritt nie ein.

Aber praktisch ... wenn's dann doch abschmiert, Systemd es neu startet _und_ es dir eine Nachricht schickt ... und das in Endlosschleife ... dann wirste wieder mit Nachrichten zugeballert ...

[scientific]

Ich meine auch die Units der Services, die du Überwachen willst. Bitte!

lg scientific

[Nastra]

Hatte ich nicht so verstanden aber es ist 17 mal diese Unit. Sind alle gleich aufgebaut, steuern nur andere Plugins an also andere EnvironmentFile Pfade und andere Description.

z.B. homebridge-hue

Code: Alles auswählen

[Unit]
Description=homebridge-soundtouch.service 
After=syslog.target network-online.target

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

[Install]
WantedBy=multi-user.target

[scientific]

UI... da gibts auch noch Verbesserungsbedarf...

Wie unterscheiden sich diese 17 Units konkret?

Wenn sich bloß "soundtouch" unterscheidet, dann erstelle eine einzige Unit die homebridge@.service heißt und folgenden Inhalt hat:

Code: Alles auswählen

[Unit]
Description=homebridge-%i.service 
After=syslog.target network-online.target

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

[Install]
WantedBy=multi-user.target

%i in der Unit wird dann durch das ersetzt, was im Aufruf der Unit zwischen dem ersten "@" und dem letzten ".service" steht.

Dann starte die Units mit

Code: Alles auswählen

systemctl start homebridge@soundtouch.service homebridge@bla.service homebridge@blubb.service

Die Config-Files müssten dann homebridge-soundtouch hombridge-bla homebridge-blubb usw. heißen

Dann pflegst du bloß eine einzige systemd-Unit und 17 Konfigs, statt 17 systemd-Units und 17 Konfigs.

Du kannst ja einmal nur deine Unit homebridge-soundtouch.service stoppen und mit der neuen homebridge@soundtouch.service starten. Wenn das funktioniert (wovon ich ausgehe), kannst du alle deine vielen Units stoppen und die neuen - sogenannte instanziierende - Units enablen mit

Code: Alles auswählen

systemctl enable homebridge@soundtouch.service homebridge@bla.service homebridge@blubb.service

lg scientific