Einleitung
In diesem Dokument wird beschrieben, wie IOX-Anwendungen, bei denen Probleme beim Einstieg oder beim unerwarteten Beenden auftreten, behoben oder gedebuggt werden.
Hintergrundinformationen
Wenn Sie IOX-Anwendungen entwickeln, ist der beste Ansatz, sie auf einer anderen Plattform und/oder Sandbox zu entwickeln. Sobald die IOX-Anwendung getestet und einsatzbereit ist, kann sie in einem Paket auf einem IOX-fähigen Gerät bereitgestellt werden. In einigen Fällen funktioniert diese Bereitstellung nicht wie erwartet, die Anwendung wird möglicherweise unerwartet beendet oder startet nicht einmal.
Das Standardverhalten für und IOX VM/Container/Anwendung ist, zu stoppen, sobald der Zielbefehl beendet wurde. Dies erschwert die Fehlerbehebung, wenn etwas Unerwartetes passiert, da alle nicht persistenten Informationen verschwinden. Eine weitere Folge ist, dass es sehr zeitaufwendig ist, wenn Sie mit den Funktionen von IOX-Anwendungen spielen bzw. experimentieren möchten. Das Starten einer anderen App/eines Ziels/Befehls/Skripts erfordert, dass Sie zumindest das Paket ändern.yaml, das neue Paket erstellen, Ihre aktuelle Anwendung deaktivieren, mit dem neuen Paket aktualisieren, die Anwendung erneut aktivieren und starten.
Grundlegende Informationen zur Beendigung von IOX-Anwendungen
Lokaler Manager und IOX-Client liefern nicht viele Informationen darüber, warum Anwendungen/Container/VMs angehalten wurden. Glücklicherweise verfolgt die watchDog.log dies und liefert Ihnen auch den letzten Exit-/Rückgabecode der Anwendung. Auch wenn dies nicht immer hilfreich ist, führt es in vielen Fällen zu dem Grund, den Sie suchen.
So rufen Sie die Datei watchDog.log mit dem IOX-Client ab:
[jedepuyd@db ~]$ ioxclient app logs tail iox_docker_test watchDog.log 10
Currently active profile : default
Command Name: application-logs-tail
App/Service : iox_docker_test, Logfile : watchDog.log, viewing last 10 lines
APP END TIME:1498207460
Time taken by App : 0 minutes and 0 seconds.
Got the ip address - 10.197.215.227 for interface eth0
All interfaces got the ips
APP START TIME:1498207536
App iox_docker_test started with PID : 11
Monitoring this process now
App iox_docker_test completed with exit code: 127
APP END TIME:1498207536
Time taken by App : 0 minutes and 0 seconds.
So rufen Sie das Protokoll mit dem lokalen Manager ab:
- Melden Sie sich bei Local Manager an.
- Wie im Bild gezeigt, klicken Sie auf Start deaktivieren verwalten für die entsprechende Anwendung

- Wählen Sie die Registerkarte Protokolle aus, wie im Bild gezeigt:

- Laden Sie die watchDog.log

Diese Anwendung wird z. B. unerwartet beendet, und Sie sehen dies in watchDog.log
APP START TIME:1498207536
App iox_docker_test started with PID : 11
Monitoring this process now
App iox_docker_test completed with exit code: 127
APP END TIME:1498207536
Wie Sie im obigen Protokollausschnitt sehen können, war der Exitcode 127. Dies ist ein reservierter Rückgabecode und bedeutet: -Befehl nicht gefunden, der anzeigt, dass ein fehlerhafter Befehl als Ziel angegeben ist, oder das gestartete Skript versucht, einen fehlerhaften Befehl aufzurufen.
Die gängigsten reservierten Exit-Codes:
| RC |
Bedeutung |
Kommentar |
| 1 |
Erfassung bei allgemeinen Fehlern |
Verschiedene Fehler, wie "divide by zero" und andere unzulässige Vorgänge |
| 2 |
Missbräuchliche Verwendung von Schalenaufbauten |
Fehlendes Schlüsselwort oder fehlender Befehl oder Berechtigungsproblem (und Diff-Rückgabecode bei einem fehlgeschlagenen Binärdateivergleich). |
| 126 |
Befehl konnte nicht ausgeführt werden |
Berechtigungsproblem oder Befehl ist keine ausführbare Datei |
| 127 |
Befehl nicht gefunden |
Mögliche Probleme mit $PATH oder einem Tippfehler |
| 128 |
Ungültiges Argument zum Beenden (RC>255) |
exit akzeptiert nur ganzzahlige Args zwischen 0 und 255. |
| Über 128 |
Schwerwiegendes Fehlersignal "n" |
exit code ergibt 137 (128 + 9) -> app error signal was 9 |
| 130 |
Beendet mit Strg+c |
Control-C ist fatales Fehlersignal 2, (130 = 128 + 2, siehe oben) |
| 255 |
Exit-Status liegt außerhalb des zulässigen Bereichs (RC>255) |
exit akzeptiert nur ganzzahlige Args zwischen 0 und 255. |
Weitere Informationen hierzu finden Sie unter: http://tldp.org/LDP/abs/html/exitcodes.html
Verhindern, dass IOX-Container bei der Anwendungs-/Zielterminierung angehalten werden
Das obige Thema enthält Informationen zur Fehlerbehebung bei einer fehlerhaften Anwendung, verhindert jedoch nicht, dass die IOX-Anwendung beendet wird. Dies bedeutet, dass die meisten wertvollen Informationen im Zusammenhang mit der Fehlerbehebung verschwunden sind, da alle nicht-persistenten Daten nicht mehr vorhanden sind.
Wie bereits erwähnt, ist es ein weiterer Anwendungsfall, mit den Möglichkeiten der gestarteten IOX-Applikation zu spielen oder mit Befehlen und Argumenten flexibel zu sein.
Um zu verhindern, dass IOX-Anwendungen am Anwendungsende beendet werden, können Sie den Befehl -debug an den Befehl activate übergeben:
[jedepuyd@db ~]$ ioxclient app activate -debug on testdebug
Currently active profile : default
Command Name: application-activate
App testdebug is Activated
[jedepuyd@db ~]$ ioxclient app start testdebug
Currently active profile : default
Command Name: application-start
App testdebug is Started
[jedepuyd@db ~]$ ioxclient app console testdebug
Currently active profile : default
Command Name: application-console
Console setup is complete..
Running command : [ssh -p 2222 -i testdebug.pem appconsole@10.48.43.197]
/ #
Im obigen Beispiel können Sie nach dem Aktivieren und Starten mit dem Flag -debug on auf den Container zugreifen, auch wenn die Anwendung beendet wird. Sie können hier weitere Befehle starten und frei mit der Anwendung in der Umgebung experimentieren, in der die Anwendung ausgeführt wird. Dies spart viel Zeit bei der Lösung von Anwendungsproblemen oder beim Ermitteln der richtigen Ziele und Argumente.