Wie debugge ich Upstart-Skripte?

67

Aus irgendeinem Grund wird bei Apport-Upgrades ein Fehler angezeigt , dessen Ursache darin besteht

% sudo service apport start
start: Job failed to start

Unter sysvinit könnte ich ein solches Problem debuggen, indem ich z

sudo sh -x /etc/init.d/whatever start

aber das scheint nicht zu Upstart zu passen. Was soll ich als nächstes versuchen?

Es stellt sich heraus, dass es eine Problemumgehung gibt, mit der die Installation fortgesetzt werden kann. Aber ich bin immer noch an der allgemeinen Frage interessiert, wie man das Drehbuch nachzeichnen würde.

Poolie
quelle
1
Ich arbeite an einer gründlicheren Antwort, aber danke für den Link zur Problemumgehung, dasselbe ist mir heute bei der Aktualisierung von natty passiert!
Mark Russell
Haha, und sie haben das Update vor 12 Minuten veröffentlicht. Macht es nicht Spaß, Beta zu laufen? (nicht wirklich!)
Mark Russell
+ Muhammad hat die richtige Antwort unten gepostet.
Travis Reeder
Ich fand nützliche Debugging-Informationen in /var/log/syslog.
Matt

Antworten:

29

Alle folgenden Informationen (und viel mehr nützliche Upstart-Hilfe) stammen aus dem Upstart-Kochbuch . Abschnitt 18 behandelt das Debuggen. http://upstart.ubuntu.com/cookbook/#debugging

In diesem speziellen Fall der Verfolgung einer Zeilengruppe "script" eines Upstart-Jobs sollten Sie die folgenden Zeilen direkt unter dem Wort "script" einfügen:

exec 2>>/dev/.initramfs/myjob.log
set -x

Der Grund für die ungerade Position ist, dass /dev/.initramfs/ sehr früh vor dem Laden des Root-Dateisystems verfügbar ist und nach dem Start weiterhin verfügbar ist. Ich vermute , mit Apport, aber Sie wahrscheinlich nicht brauchen , diesen Weg zu benutzen. Trotzdem ist es schön, die Option zu kennen.

Es sollte auch beachtet werden, dass alle Skripte mit ausgeführt werden, set -esodass jeder Befehl, der fehlschlägt, das Skript vollständig beendet. Was Sinn macht, da man beim Ausführen von Skripten als root sehr vorsichtig sein sollte.

Ich empfehle allen, die mit Upstart-Jobs arbeiten, dringend, das oben verlinkte Upstart-Kochbuch zu konsultieren.

Mark Russell
quelle
Vielen Dank, wenn ich nicht gesehen hätte, dass der Fehler behoben ist, hätte ich das Skript wahrscheinlich so geändert, dass es set -xwie von Ihnen vorgeschlagen aktiviert wird. Ich habe mich meist gefragt, ob es einen saubereren Weg dafür gibt.
Poolie
Ja, nicht das ich wüsste (und wenn es nicht im Kochbuch steht, heißt das, dass es wahrscheinlich einfach keine gibt). Abgesehen von dieser Idee geht es bei den meisten der erwähnten Debugging-Techniken mehr um die Fehlerbehebung bei Upstart- und Upstart-Ereignissen selbst, wo ich mich normalerweise befinde. :)
Mark Russell
Diese Methode schlägt jedoch fehl, wenn setuidund setgidin Jobs verwendet werden.
0xC0000022L
/dev/.initramfs ist nicht immer vorhanden. Ich bin gerade auf eine Maschine gestoßen, die diesen Pfad nicht hat.
Sarge Borsch
110

Upstart protokolliert Ihre Dienstausführung in einer Protokolldatei mit demselben Namen in /var/log/upstart/your-service-name.log. Es sollte hilfreich sein.

Muhammad Gelbana
quelle
2
Richtig, es sieht so aus, als ob dies den Stderr der Jobs beinhaltet. Wenn ich ihn also aktiviert set -xhätte, würde er wahrscheinlich dort auftauchen.
Poolie
1
Ich habe in mein Skript /etc/init.d/Xservice eine echobasierte Protokollanweisung eingefügt, die jedoch an dieser Stelle nicht angezeigt wird! OS: Ubuntu 14.04 Trusty
Champ
Warum nicht zu Syslog? Darf ich eine allgemeine Funktion vorschlagen, vielleicht rsyslog selbst, die von upstart und jeder Komponente zum Schreiben in syslog verwendet wird, wenn sie nicht verfügbar ist, oder an einen temporären Ort, der so schnell wie möglich an syslog übertragen wird. Ich brauchte einen halben Tag, um das zu finden. Bitte leiten Sie diese Bemerkung TIA weiter.
Papou
4
Dies scheint in 16.04 anscheinend seit 15.10 nicht mehr der Fall zu sein: Die letzten Dateien in diesem Verzeichnis stammen aus der Zeit unmittelbar vor der Veröffentlichung von 15.10.
FGM
1
@FGM Das liegt daran, dass 16.04 nicht mehr upstart verwendet, sondern systemd. Der Zugriff auf die Protokolle erfolgt mitjournalctl
Jeremy,