@bonvie:
Das ist etwas komplizierter zu realisieren. Angenommen, man überwacht es mit einer unabhängigen Instanz, dann einfach regelmäßig anhand der Prozessliste prüfen bzw. - da das Skript ja sein PID-File "pflegt" - aus dem PID-File (wenn es existiert) den Wert auslesen und prüfen, ob der Prozess noch existiert - in etwa so:
Code:
scriptname=callmonitor
if [ -f /var/run/$scriptname.pid ]; then
if [ -L /proc/$(cat /var/run/$scriptname.pid)/fd/0 ]; then
dead=0
else # PID file still exists, but there's no associated process anymore
dead=1
fi
else # PID file deleted, usually the script is not running anymore
dead=1
fi
if [ $dead -eq 0 ]; then
echo "alive"
else
echo "dead"
fi
Das oben stehende ist nur als Denkanstoß gedacht, nicht getestet und "nur so hingeschrieben" ... also eher nicht C&P geeignet, wenn ich einen Syntaxfehler o.ä. übersehen habe bzw. ich würde wahrscheinlich anstelle des direkten Symlink-Tests erst noch einen "IsDirectory"-Test für /proc/$PID machen, weil das die "saubere" Lösung wäre.
Wenn der Prozess tatsächlich beendet wird, weil das 'nc' ein EOF vom Socket erhält (das passiert dann, wenn der 'telefon'-Daemon aus irgendeinem Grund neu gestartet wird), dann könnte man natürlich im ursprünglichen Skript am Ende (nach dem rm für's PID-File) noch ein "sleep irgendwas" und einen anschließenden Neustart über den multid mit einem passenden "delay"-Kommando einbauen.
Das müßte dann aber am besten als "detached" laufen und richtet bei passend gewählten Einstellungen auch keinen weiteren Schaden an, da das "delay" natürlich bei nicht aktivem multid (z.B. bei der Ausführung von /var/post_install im Rahmen eines Reboots) wirkungslos bleibt. Trotzdem muß natürlich ein entsprechendes "sleep" vor dem "delay" sein, denn wenn tatsächlich der "telefon"-Daemon bei irgendwelchen Rekonfigurationen neu gestartet wird, dann ist das mit einiger Sicherheit beim "multid" auch der Fall (der "stirbt" schon beim Rekonfigurieren von VPN-Verbindungen - da muß man "long running scripts" auch entsprechend härten, wenn man über "delay" startet und nicht über einen cron-Daemon, weil man mit AVM-Busybox arbeitet) und dann stirbt der "delaystart"-Job (den könnte man auch mit einem passenden "msgsend multid delaystart ..." selbst einrichten, etwas anderes macht "delay" als Binary auch nicht) mit ihm.
Wenn man also eine Busybox mit crond-Support hat, kann man diese ja problemlos für alle möglichen regelmäßigen Jobs einspannen, dabei dann eben auch für die unabhängige Überwachung. Ansonsten muß man sich eben überlegen, wie man die Überwachung von Prozessen generell organisiert.
Ich habe bei fast allen Kunden auf der Box dafür ein Skript mit einer einzigen "sleep 5"-Schleife laufen, was anhand einer Parameter-Datei mit den zu überwachenden Prozessen (Binary-/Skript-Name, Prüfintervall, PID-File, Start-Parameter) in einem einzelnen "Monitor"-Prozess die anderen überwacht (in etwa so wie oben skizziert) und entsprechende Aktionen vornimmt. Das ist aber weder gut dokumentiert noch sehr allgemein gehalten, das Hinzufügen von neuen Prozessen (bzw. das Löschen von alten) ist auch Bestandteil eines größeren Helper-Skripts, das ich erst auseinandernehmen müßte. Daher will ich es nicht unbedingt zur Verfügung stellen - das ist im Moment mehr ein Beispiel, wie man es nicht machen sollte und die Zeit, um das mal richtig zu machen, fehlt bisher.
EDIT: Um das noch einmal zu verdeutlichen ... wenn man eine eigene Busybox hat und dort die "run service"-Applets (es gibt einige, die zu diesem Komplex gehören) zur Verfügung stehen, dann braucht man die ganze Monitor-Geschichte eigentlich nicht, da die "runsv"-Architektur ja genau auf solche Fälle ausgerichtet ist. Um die Wirkungsweise zu verstehen, ist eine Internet-Suche nach "man runsv" zu empfehlen, die Hilfe zum Applet ist da eher weniger üppig. Mit einem passenden run-Skript läßt sich ein Service immer wieder neu starten, solange sein Monitor-Prozess läuft ... bei vorhandenem finish-Skript kann man auch "Nachbereitung" betreiben und z.B. Protokoll-Dateien sichern/rotieren o.ä. - der Phantasie sind da keine Grenzen gesetzt, man sollte nur dafür sorgen, daß solche Geschichten dann beim Update (prepare_fwupgrade) und beim Neustart (post_install) nicht zu Kuddelmuddel führen und sie entsprechend mit stoppen, indem man diese Skripte passend modifiziert. Bei post_install ist das ganz leicht (liegt ja im beschreibbaren tmpfs unter /var), bei prepare_fwupgrade muß man auch nur eine einzige passende Zeile einfügen und das mache ich bei mir schon immer prophylaktisch am Anfang solcher "terminate"-Scripte - so in der Art: "[ -f my_file_name ] && . my_file_name", damit passiert auch nichts, wenn die Datei nicht existiert, man hat aber immer einen "Hook" zum Eingreifen.
