Soweit ich das beurteilen kann.
Hintergrundjobs werden daran gehindert, das Terminal des Benutzers zu lesen. Wenn man dies versucht, wird es ausgesetzt, bis der Benutzer es in den Vordergrund bringt und eine Eingabe macht. "Lesen vom Terminal des Benutzers" kann bedeuten, dass entweder direkt versucht wird, vom Terminal zu lesen, oder Terminaleinstellungen geändert werden.
Normalerweise ist das das, was Sie wollen, aber manchmal lesen Programme vom Terminal und/oder ändern Terminaleinstellungen, nicht weil sie Benutzereingaben benötigen, um fortzufahren, sondern weil sie überprüfen möchten, ob der Benutzer versucht, Eingaben zu machen.
http://curiousthing.org/sigttin-sigttou-deep-dive-linux hat die blutigen technischen Details.
In Linux und anderen Unix-Systemen ein Job, der im Hintergrund läuft, aber noch seinen stdin
hat (oder std::cin
), das mit seinem steuernden Terminal (auch bekannt als das Fenster, in dem es ausgeführt wurde) verknüpft ist, wird ein SIGTTIN
gesendet Signal, das standardmäßig dazu führt, dass das Programm vollständig gestoppt wird, bis der Benutzer es in den Vordergrund bringt (fg %job
o.ä.), um tatsächlich Eingaben an das Programm zu ermöglichen. Um zu vermeiden, dass das Programm auf diese Weise angehalten wird, haben Sie folgende Möglichkeiten:
- Stellen Sie sicher, dass die Programme
stdin
Der Kanal ist nicht mehr mit dem Terminal verbunden, indem er entweder auf eine Datei mit entsprechendem Inhalt für die Eingabe durch das Programm oder auf/dev/null
umgeleitet wird wenn es wirklich keine Eingabe braucht - z.B.myprogram < /dev/null &
. - Beenden Sie das Terminal nach dem Start des Programms, wodurch die Verbindung mit dem
stdin
des Programms hergestellt wird wegzugehen. Dies führt jedoch zu einemSIGHUP
an das Programm zu liefern (was bedeutet, dass der Ein-/Ausgabekanal "aufgehängt" wurde) - dies führt normalerweise dazu, dass ein Programm beendet wird, aber dies kann durch Verwendung vonnohup
vermieden werden - z.B.nohup myprogram &
.
Wenn Sie überhaupt daran interessiert sind, die Ausgabe des Programms zu erfassen, ist dies wahrscheinlich die beste Option, da es beide der oben genannten Signale (sowie ein paar andere) verhindert und die Ausgabe speichert, damit Sie sie prüfen können, um festzustellen, ob Es gibt Probleme mit der Programmausführung:
nohup myprogram < /dev/null > ${HOME}/myprogram.log 2>&1 &
Ja, es ist wirklich gestoppt und arbeitet nicht mehr im Hintergrund. Um es wieder zum Leben zu erwecken, geben Sie fg
ein job_number