Ich habe ein Bash-Skript start.sh, das so aussieht:

for thing in foo bar; do
    {
        background_processor $thing
        cleanup_on_exit $thing
    } &
done

Das macht was ich will: Ich starte start.sh, es wird mit Code 0 beendet und die beiden Subshells laufen im Hintergrund. Jede Unterschale läuftbackground_processor, und wenn das beendet ist, läuft escleanup_on_exit. Dies funktioniert auch, wenn ich das Terminal verlasse, von dem aus ich ursprünglich start.sh ausgeführt habe (auch wenn dies eine ssh-Verbindung war).

Dann habe ich es versucht:

ssh user@host "start.sh"

Dies funktioniert, außer dass danachstart.sh hat beendet, ssh wartet offenbar auch darauf, dass die Subshells beendet werden. Ich verstehe nicht wirklich warum. Einmalstart.sh Exits, die Subshells werden zu Kindern von PID 1, und ihnen wird nicht einmal ein Tty zugewiesen. Daher kann ich nicht verstehen, wie sie noch mit meiner SSH-Verbindung verknüpft sind.

Ich habe es später versucht:

ssh -t user@host "start.sh"

Jetzt haben die Prozesse eine zugewiesene Pseudo-Tty. Jetzt stelle ich fest, dass ssh sofort beendet wirdstart.sh Exits, aber es bricht auch die untergeordneten Prozesse.

Ich vermutete, dass die untergeordneten Prozesse im letzteren Fall SIGHUP gesendet wurden, also habe ich Folgendes getan:

ssh -t user@host "nohup start.sh"

Das funktioniert tatsächlich! Also, ich habe eine Lösung für mein praktisches Problem, aber ich möchte die Feinheiten des SIGHUP / tty-Materials hier verstehen.

Zusammenfassend sind meine Fragen:

Warum wartet ssh (ohne -t) auch danach noch auf die untergeordneten Prozesse?start.sh Ausgänge, obwohl sie Eltern-PID 1 haben?Warum beendet ssh (mit -t) die untergeordneten Prozesse, anscheinend mit einem SIGHUP, obwohl dies nicht der Fall ist, wenn ich sie von einem Terminal aus starte und mich von diesem Terminal abmelde?