[linux-l] Mit Pipe erzeugte Prozesse "a | b" im Supervisord kontrollieren

[Volker Grabsch]

Liebe Liste,

ich habe eine Pipe aus 2 Prozessen, "a | b", wobei der erste
Prozess "a" recht schnell beendet ist, und der Prozess "b"
danach ewig laufen soll. Möchte ich nun diesen überwachen,
so überwache ich in Wirklichkeit den darüber liegenden Shell-
Prozess, der die Pipe verwaltet. Wird dieser gekillt ö.ä.,
betrifft das den Prozess "b" nicht mehr.

Kann ich die Pipe

     a | b

anders formulieren, sodass das Ergebnis mit Supervisord oder
Daemontools überwachbar ist? Mit fällt spontan nur ein, die
Ausgabe von "a" zwischenzulagern:

     a > /tmp/a; b < /tmp/a

Das funktioniert wieder perfekt. Etwas besser wäre sogar:

     a > /tmp/a; exec b < /tmp/a

Aber dann muss ich mich um die Sicherheit der temporären Datei
kümmern, d.h. die "saubere" Variante dieser Lösung wäre
deutlich komplexer.

Gibt es noch weitere Ideen, was man da machen kann?


Hintergrund: Ich versuche mich an einem Administrator-Tool,
das im Wesentlichen Shell-Code aus Templates erzeugt, so
einfach und transparent wie möglich. Der Prozess "a" ist
z.B. ein "xlstproc" und erzeugt den Shell-Code. Der Prozess
"b" ist einfach die Shell, z.B. "sh". So kann ich das
Template testen via:

    xsltproc ...

und wenn ich zufrieden bin, starte ich das via:

    xsltproc ... | sh

und teste das laufende System. Mit Ctrl+C kann ich das
jederzeit abbrechen, abändern, und nochmals starten.
Kirz: An der Kommandozeile arbeitet sich das damit wunderbar!

Aber wenn ich das dann "richtig" laufen lassen will, will
ich diese kurze Zeile einfach in den Supervisord bzw.
Daemontools packen. Muss ich dazu den Umweg über die Temp-Datei
gehen, oder gibt es da irgendwas Geschickteres?

BTW, der Shell-Code trifft i.d.R. irgendwelche Vorbereitungen
(iptables-Regeln, Konfiguration anpassen) und startet dann
einen Prozess (z.B. KVM, DHCP-Daemon, etc.) im Vordergrund.

Das ganze Konzept ist mir irgendwann einmal eingefallen,
als mich die Komplexität der sogenannten "Configuration-
Manager" zu sehr genervt hat. Es arbeitet sich wunderbar
damit, nur dieses eine dumme "Detail"-Problem macht es
leider ungeeignet für einen echten Produktiv-Einsatz, um
weitere Erfahrungen damit zu sammeln.

Für Ideen und Vorschläge wäre ich sehr dankbar.


Gruß
Volker

-- 
Volker Grabsch
---<<(())>>---