Beobachten Sie gleichzeitig Signale und verarbeiten Sie den Exit in der Bourne-Shell

8

Ich habe ein Bourne-Shell-Skript (/ bin / sh) (für Portabilität), das ein anderes Programm überwachen möchte. Es sollte das andere Programm starten und darauf warten, dass es beendet wird. Wenn das zweite Programm beendet wird, führt es einige abschließende Arbeiten aus und beendet sich selbst. Der Haken ist, dass das Skript auch auf Signale reagieren muss (zB USR2) und etwas arbeiten muss, wenn diese Signale auftauchen.

Meine naive Implementierung ist:

%Vor%

Das funktioniert nicht. Wenn ich die Shell SIGUSR2 sende, wird der Trap wie erwartet ausgelöst, aber die Wartezeit wird ebenfalls beendet und 140 zurückgegeben. Das / bin / sleep-Programm wird auf seinem fröhlichen Weg fortgesetzt. Typische Ausgabe:

%Vor%

Dieses Verhalten ist konsistent zwischen Dash und Bash, den beiden Bourne-Shell-Derivaten, auf die ich bequem zugreifen kann.

Meine derzeitige Arbeit besteht darin, die Schleife zu drehen, während ich darauf warte, dass die Kind-PID verschwindet, indem ich mit Kill sondiere. Spin-Looping scheint verschwenderisch zu sein und vergrößert das Fenster, in dem mein Skript fälschlicherweise auf den falschen Prozess wartet, wenn PIDs schnell wiederverwendet werden.

%Vor%

Gibt es eine bessere Lösung angesichts meines Ziels, gleichzeitig darauf zu warten, dass ein anderer Prozess beendet wird und auf Signale reagieren kann?

    
Alan De Smet 20.07.2012, 20:53
quelle

1 Antwort

3

Sie könnten tun:

%Vor%

Beachten Sie jedoch Folgendes aus dem sh-Standard:

Wenn der Beendigungsstatus von wait größer als 128 ist, gibt es für die Anwendung keine Möglichkeit zu wissen, ob der Wartenprozess mit diesem Wert beendet oder durch ein Signal beendet wurde. Da die meisten Dienstprogramme mit kleinen Werten enden, gibt es selten Mehrdeutigkeiten. Selbst in den mehrdeutigen Fällen müssen die meisten Anwendungen nur wissen, dass der asynchrone Job fehlgeschlagen ist. Es spielt keine Rolle, ob es einen Fehler festgestellt hat und fehlgeschlagen ist oder getötet wurde und seine Aufgabe nicht normal beendet wurde.

In diesem Fall ist die Ambiguität etwas anders. Sie wissen nicht, ob die Wartezeit durch das Signal unterbrochen wurde oder ob das Kind durch ein Signal beendet wurde.

    
William Pursell 22.07.2012, 13:41
quelle

Tags und Links