Da Sie sagen, dass Sie das Skript bearbeiten können sich einfach ein setzen:
ps -ef >/tmp/bash_stack_trace.$$
darin, wo das Problem auftritt.
Dies erstellt eine Reihe von Dateien in Ihrem Verzeichnis tmp
, die die gesamte Prozessliste zu dem Zeitpunkt zeigen, als es passiert ist.
Sie können dann herausfinden, welcher Prozess welchen anderen Prozess aufgerufen hat, indem Sie diese Ausgabe untersuchen. Dies kann entweder manuell erfolgen oder automatisiert mit so etwas wie awk
, da die Ausgabe regulär ist -. Sie gerade jene PID
und PPID
Spalten verwenden, um die Beziehungen zwischen allen Prozessen zu arbeiten, der Sie interessiert
Sie über Sie müssen die Dateien im Auge behalten, da Sie pro Prozess einen erhalten, so dass sie möglicherweise verwaltet werden müssen. Da dies nur während des Debuggens durchgeführt werden sollte, wird die Zeile meistens auskommentiert (vorangestellt von), sodass die Dateien nicht erstellt werden.
zu reinigen, können Sie einfach tun:
rm /tmp/bash_stack_trace.*
dass, obwohl kein Stack-Trace ist. im besten Fall wäre es eine Exec-Spur. Aber dafür wären
pstree -pal
oderps -ef --forest
besser geeignet.Es zeigt nicht den Funktionsaufruf * stack *, noch zeigt es die aktuelle Code-Datei und Zeile. Was normalerweise der springende Punkt einer Stack-Spur ist. – Evi1M4chine
Ja, aber OP erklärte, dass sie nur wissen wollten, welche Skripte welche Skripte aufrufen, so dass die Details, welche Zeilen innerhalb der Skripte notwendig sind, nicht notwendig sind. Sobald Sie den exec-stack kennen, können Sie Debug-Anweisungen wie 'set -x' zu einzelnen Skripten hinzufügen, um eine feinkörnigere Ablaufverfolgung zu erhalten. – paxdiablo
Ich halte dies nicht für eine Antwort auf die Frage, zumindest nicht im üblichen Sinne des Stack-Trace. – akostadinov