[umgangen] supervisor mit Script zum überwachen von kern.log

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
Benutzeravatar
ingo2
Beiträge: 1125
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

[umgangen] supervisor mit Script zum überwachen von kern.log

Beitrag von ingo2 » 07.07.2020 22:11:12

Habe mir folgenedes Script zum Monitoren von /var/log/kern.log erstellt:

Code: Alles auswählen

#!/bin/bash

# /usr/local/bin/monitor-log
#
# Monitor $LOGFILE for a pattern $PATTERN.
# Perform an action when $PATTERN matches.

LOGFILE=/var/log/kern.log
PATTERN='Mismatch'
tail -Fn0 $LOGFILE | \
while read line; do
    echo "$line" | grep -i "$PATTERN" > /dev/null
    if [ $? = 0 ]
    then
        sleep 10
#       echo "0000:00:10.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
        echo '1-2' > /sys/bus/usb/drivers/usb/unbind
        sleep 5
#       echo "0000:00:10.0" > /sys/bus/pci/drivers/xhci_hcd/bind
        echo '1-2' > /sys/bus/usb/drivers/usb/bind
#       echo "USB-xHCI root hub rebound" | mail -s xHCI root
        echo "RTL2838UHIDIR rebound" | mail -s xHCI root
    fi
done
Das Script wird von Debiansupervisor gestartet und überwacht, d.h. im Fall eines Treffers oder Absturzes wieder neu gestartet.

Das funktioniert seit Wochen einwandfrei und ich hatte schon 3 Blockaden des USB-Ports, die durch unbind/bind des xhci_hcd Moduls sofort gelöst wurden. Heute habe ich im Script eine Änderung vorgenommen und es läuft der Versuch, ob es reicht, das auf den betreffenen USB-Port (mit dem RTL-SDR-Stick) anzuwenden.

Um das Script neu einzulesen, genügt ein

Code: Alles auswählen

supervisorctl restart monitor_log
Dabei ist mir aufgefallen, dass
Das laufende Script insgesamt 3 PID's erzeugt, z.B. aktuell

Code: Alles auswählen

19237 monitor-log
19238 tail
19239 monitor-log
Nach dem restart verbleiben aber 2 PID's in der Prozessliste:

Code: Alles auswählen

pgrep -l monitor-log 
19081 monitor-log        # Zombie
19237 monitor-log
19239 monitor-log

pgrep -l tail
566 tail          # alt
18678 tail        # alt
18694 tail        # alt
19080 tail        # Zombie
19238 tail
wobei die ersten 3 PID's von tail offenbar aus der Vergangenheit (3 Neustarts wegen Treffer) stammen.

Ok, die Zombi-PID's von monitor-log kann ich einfach vermeiden, indem ich statt über supervisotctl das Script nach Änderung einfach durch

Code: Alles auswählen

killall monitor-log
neu einlese/starte.

Die tail-PID's sind mir erst heute aufgefallen, da ich dachte, die 2te monitor-log-PID stammt aus meiner Loop im Script.

Was mache ich da falsch, oder wie kann ich diese Zombi-PID's vermeiden?

Gruß, Ingo
Zuletzt geändert von ingo2 am 09.07.2020 20:31:48, insgesamt 1-mal geändert.

Benutzeravatar
ingo2
Beiträge: 1125
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

Re: supervisor mit Script zum überwachen von kern.log

Beitrag von ingo2 » 08.07.2020 20:24:45

So, zumindest habe ich jetzt eine Lösung gefunden, um das Script zuverlässig neu einzulesen:
vorher:

Code: Alles auswählen

$ pgrep -l moni
22714 monitor-log
22716 monitor-log

$ pgrep -l tail
22715 tail
und nach killen von tail mit

Code: Alles auswählen

# killall tail
laufen/starten wieder alle 3 Prozesse mit neuen PID's:

Code: Alles auswählen

$ pgrep -l moni
23513 monitor-log
23515 monitor-log

$ pgrep -l tail
23514 tail
Und funktionieren wie gewünscht tut es auch.
Sauber restarten mit supervisorctl klappt aber immer noch nicht.
Zuletzt geändert von ingo2 am 08.07.2020 21:34:33, insgesamt 1-mal geändert.

JTH
Moderator
Beiträge: 3077
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: supervisor mit Script zum überwachen von kern.log

Beitrag von JTH » 08.07.2020 21:22:52

Hilft dir nen

Code: Alles auswählen

stopasgroup=true
in der Config für den supervisord?
Manchmal bekannt als Just (another) Terminal Hacker.

Benutzeravatar
ingo2
Beiträge: 1125
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

Re: supervisor mit Script zum überwachen von kern.log

Beitrag von ingo2 » 08.07.2020 22:02:49

Bringt leider nichts - die endlose while-Schleife ist offenbar nicht Teil einer "group". Laut Doku muß man Gruppen wohl vorher definieren, d.h. einzelne Prozesse zusammenfassen.

Ich hab' auch schon versucht, die Funktionalität ohne die while-Schleife zu realisieren, aber ein

Code: Alles auswählen

tail -Fn0 $LOGFILE  | grep -q "$PATTERN"
if [ $? = 0 ]
...
hat aber nicht funktioniert.

Benutzeravatar
ingo2
Beiträge: 1125
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

Re: supervisor mit Script zum überwachen von kern.log

Beitrag von ingo2 » 09.07.2020 20:30:48

So, ich habe das Problem jetzt nach vielen Recherchen ganz pragmatisch gelöst.

Ich verzichte auf die "real time" Aktion, bei der der "unbind/bind" für den blockierten USB-Port sofort ausgeführt wird und mache das Ganze asynchron mit einem "cron-job" alle 15 Minuten. Da geht mir maximal ein Temperatur-Meßwert des RTL-SDR-Sticks verloren. Genau für diesen Weg gibt's ein fertiges Tool im Repo: Debianlogtail.

Damit ist jetzt der Log-Check ein einfacher cron-job, der im Trefferfall ein simples lineares Script für den "rebind" auführt:

Code: Alles auswählen

# Check every 15 min. for new "Mismatch" in kern.log and execute rebind-rtl if found
5,20,35,50 * * * * root	/usr/sbin/logtail2 /var/log/kern.log | grep -q "Mismatch" && /usr/local/bin/rebind-rtl
Und das Script ist denkbar simpel:

Code: Alles auswählen

# To find out the USB-Device-ID of the Port where the RTL-SDR is attached to, issue:
# for device in $(ls /sys/bus/usb/devices/*/product); do echo $device;cat $device;done
#   /sys/bus/usb/devices/1-2/product
#   RTL2838UHIDIR

echo '1-2' > /sys/bus/usb/drivers/usb/unbind
sleep 10
echo '1-2' > /sys/bus/usb/drivers/usb/bind
echo "RTL2838UHIDIR rebound" | mail -s "USB-Port 1-2" root
Fazit: nicht solved, sondern umgangen.

Antworten