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
stdinDer 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/nullumgeleitet 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
stdindes Programms hergestellt wird wegzugehen. Dies führt jedoch zu einemSIGHUPan 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 vonnohupvermieden 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