Ich habe die Antwort mit etwas anderen Suchbegriffen gefunden:expect stop
Leider bedeutet dies, dass Upstart den ersten Aufruf von sed als erste PID erkennt
Außerdem ist die Antwort auf einen Workaround in der Nähe pre-start
, der genau für diesen Zweck entwickelt wurde. Ich habe nicht darüber nachgedacht, obwohl ich es schon in den Dokumenten gelesen habe ...
Ich habe auch einen interessanten Vorschlag gefunden: Möglichkeit, explizit zu sagen, welche PID zu verfolgen ist
Aufgrund einiger Probleme bei einem meiner Dienste habe ich noch einmal nachgeschaut, wie es sich mit Upstart verhält, und Folgendes gefunden: Meine Zeilengruppe "script" ruft immer noch Binärdateien wie "dirname", "readlink" und "ls" auf harter Code ein funktionierendes Verzeichnis, Java-Klassenpfad erstellen und so weiter. Der wichtige Teil ist, dass diese keine eingebauten Shell sind und daher von Upstart nachverfolgt werden sollten, da "readlink" die erste in "start" ausgeführte Binärdatei ist. Dies ist jedoch nicht der Fall, diese PIDs scheinen ignoriert zu werden und Upstart verfolgt stattdessen die PID des Befehls "exec java ...", den ich wirklich verfolgt sehen möchte. Ich habe das überprüft, indem ich "service ... status" aufrief und die Ausgabe mit "ps axf | grep ..." vergleiche und beide PIDs übereinstimmen.
Zwei mögliche Erklärungen: Da "dirname" und Co. als Befehlssubstitution verwendet werden, erkennt Upstart die erstellten Subshells anhand der von ihr selbst erstellten Shell für die Zeilengruppe "script" und ignoriert diese PIDs zweckmäßig. Andernfalls kann "exec" eine PID zurückgeben, die eine zuvor erkannte PID überschreibt. Ich bezweifle das Letztere und denke, dass Subshells einfach ignoriert werden, was dann ein sehr schönes Feature ist.