PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wo landen Fehler-Ausgaben von Childs?



7.e.Q
15.04.04, 06:29
Guten Morgähn!

Also folgendes Problem:

Ich habe für unser Embedded-System ein Programm entwickelt, welches quasi als Loader fungiert. Auf dieses Programm verbindet sich ein anderes Programm von einem anderen Rechner aus via TCP und läd dieses System mit einer Ladesoftware. Die Ladesoftware wird als Child des Loaders gestartet (also via fork und exec). Nun muss ich aber exakt wissen, ob die Ladesoftware vernünftig gestartet wurde, noch läuft, abgestürzt ist, fehlerhaft beendet wurde oder was sonst noch. Also muss ich die Fehlerausgaben des Childs (Ladesoftware) im Parent (Loader) irgendwie sichtbar und lesbar machen können. Dabei handelt es sich um Fehlermeldungen wie "Segmentation Fault", "Floating Point Exception" oder auch die auftretenden Meldungen bei Fehlen einer Bibliothek. Alle normalen Ausgaben der Ladesoftware sind im Loader bereits verfügbar, da ich die Standard-Ausgabe-Konsole der Ladesoftware entsprechend in eine FIFO umgelenkt habe (close... open... dup2... etc.) Das selbe habe ich auch mit der Standard-Fehler-Ausgabe gemacht. Jedoch kommen die Fehlermeldungen im Gegensatz zu den normalen Ausgaben und Meldungen NICHT im Loader an. Daher meine Fragen:

Auf welcher Konsole landen die Fehlermeldungen "Segmentation Fault" etc. eines fehlerhaften Child-Prozesses und wo muss ich diese umlenken?

Woran erkenne ich, wenn ein mit fork/exec gestarteter Child fehlerhaft ist, also nicht wie vorgesehen gestartet wurde?

Wäre klasse, wenn mir das jemand beantworten könnte.

Danke!
Gruß, Hendrik

asddas
15.04.04, 20:39
Auf welcher Konsole landen die Fehlermeldungen "Segmentation Fault" etc. eines fehlerhaften Child-Prozesses und wo muss ich diese umlenken?

Woran erkenne ich, wenn ein mit fork/exec gestarteter Child fehlerhaft ist, also nicht wie vorgesehen gestartet wurde?


Der Vaterprozess muss auf den Kindprozess mit waitpid(); warten. Diese Funktion gibt den Return Code des Programmes (bzw. Funktion) zurück. Also müsstest du im Vater dann die entsprechenden Ausgaben machen.

Ansonsten www.mrunix.de

7.e.Q
15.04.04, 20:52
Der Vaterprozess muss auf den Kindprozess mit waitpid(); warten. Diese Funktion gibt den Return Code des Programmes (bzw. Funktion) zurück. Also müsstest du im Vater dann die entsprechenden Ausgaben machen.

Ansonsten www.mrunix.de

Das Problem bei der Sache ist, daß der Loader nicht nur eine Ladesoftware, also einen Child verwalten muss, sondern neun an der Zahl. Parallel. Ist das mit waitpid auch noch möglich?

Welche Return-Codes entsprechen welchem der folgenden Fehler:

Segmentation Fault
Floating Point Exception (DIV/0)
fehlende Bibliothek

Das sind die drei hauptsächlich auftretenden Fehler beim Starten einer unserer Childs, sofern überhaupt einer auftritt. :cool: Und diese Fehler muss der Parent nicht nur erkennen sondern auch unterscheiden können. Und er muss demnach Maßnahmen einleiten können (Meldung an die Bedienungs-Oberfläche o.ä.), aber das ist ein anderes Thema. Mir geht es darum, daß der Parent jedwedes Fehlverhalten der neun Childs überwachen, erfassen und melden kann, ohne zu blockieren.

asddas
15.04.04, 21:16
Das Problem bei der Sache ist, daß der Loader nicht nur eine Ladesoftware, also einen Child verwalten muss, sondern neun an der Zahl. Parallel. Ist das mit waitpid auch noch möglich?


Klar geht das du hast ja deren pid. Waitpid ermöglicht auch das warten auf eine spezielle pid.



Welche Return-Codes entsprechen welchem der folgenden Fehler:

Segmentation Fault
Floating Point Exception (DIV/0)
fehlende Bibliothek


man waitpid ;)
Ich denke das Makro WSTOPSIG(status) bzw WEXITSTATUS(status) ist da ganz nützlich.

Wieso führ das fehlen eine Bibliothek zu einem Absturz? Sowas sollte vorher überprüft werdem

7.e.Q
16.04.04, 06:03
Klar geht das du hast ja deren pid. Waitpid ermöglicht auch das warten auf eine spezielle pid.



man waitpid ;)
Ich denke das Makro WSTOPSIG(status) bzw WEXITSTATUS(status) ist da ganz nützlich.

Wieso führ das fehlen eine Bibliothek zu einem Absturz? Sowas sollte vorher überprüft werdem

Okay, rtfm... hätt ich auch drauf kommen können. ;) Danke! Das ist ja nun aber Polling-Betrieb. Gibt es da keine Möglichkeit das auf Interrupt-Basis zu machen?

Keine Möglichkeit, die Fehlermeldung, die das System anhand des vom Child verursachten Fehlers ausgibt, bspw. in eine Pipe oder einen Socket umzuleiten?

7.e.Q
16.04.04, 06:40
So, habe das eben ausprobiert und festgestellt, da ich mit mehreren zu überwachenden Childs arbeite und daher WNOHANG im waitpid benutzen muss, daß mir waitpid dann -1 zurückliefert.

Ich frage den Status aller 8 Childs alle 500ms ab. Daher bekomme ich nur mit, daß der entsprechend beendete Child nicht mehr existiert. Ich bekomme aber nicht den Rückgabewert, sondern lediglich 0 (läuft noch) oder -1 (existiert nicht mehr).

Wie kann ich waitpid ohne WNOHANG dazu bringen, nicht zu blockieren?

Wie kann ich anders als mit waitpid den Status eines Childs erfragen?

Wie erhalte ich den Returncode eines Prozesses mit einer nicht mehr existierenden PID?

sticky bit
16.04.04, 09:39
Weiss nicht obs Dir im konkreten Falle hilft, aber AFAIK bekommst du das Sterben eines Childs im Parent durch das SIGCHLD Signal mit.
Andererseits könnteste vom Child aus auch Signal Handler bauen, die bei Fehlern eben diesen irgendwohin schreiben (Socket etc...) und den Prozess erst beenden lassen wenn diese Nachricht abgehohlt wurde. Mit einem der beiden benutzer definierten Signale SIGUSR1 und SIGUSR2 könnteste dem Parent vielleicht signalisieren, dass es was zu hohlen gibt.
Nur n theoretischer Ansatz keine Ahnung ob sowas (gut) geht, aber vielleicht kannst was draus machen...

7.e.Q
16.04.04, 10:41
Also das mit waitpid hat nach ein paar Stunden Debugging funktioniert. Jetzt hat ich die PID zusammen mit dem Returncode und dem Signal. :)

Danke!