Si vous avez vraiment un travail de premier plan, alors bash attend qu'il se termine, c'est plus ou moins la définition d'un travail de premier plan . Si bash a toujours le contrôle du terminal, vérifiez ce qui se passe jobs -l
, par exemple:
$ ncat -kl -p 10111 &
[1] 13404
$ ncat -kl -p 10222 &
[2] 13405
$ ncat -kl -p 10333 &
[3] 13406
$ jobs -l
[1] 13404 Running ncat -kl -p 10111 &
[2]- 13405 Running ncat -kl -p 10222 &
[3]+ 13406 Running ncat -kl -p 10333 &
J'ai commencé trois ncat
processus d'écoute en arrière-plan pour cela. Vous pouvez également voir "Terminé" ou "Arrêté" pour un statut de travail.
Vous pouvez efficacement mettre en arrière-plan un travail de premier plan à partir d'un autre shell à l'aide de la méthode SIGSTOP / SIGCONT de Stefan Seidel (bien que le signal réel envoyé par un shell avec Ctrl- Zsoit SIGTSTP, l'un ou l'autre signal devrait fonctionner).
Il existe une distinction subtile entre les processus et les travaux lorsque les termes premier plan et arrière-plan sont utilisés. Il n'y a qu'un seul travail de premier plan du shell , il peut y avoir plusieurs processus de premier plan (cela est lié aux ID de groupe de processus terminaux et peut être observé lorsque vous démarrez deux processus ou plus dans un pipeline).
Un processus en cours d'exécution ou un pipeline sous le contrôle du shell est appelé un «travail», lorsque vous utilisez la commande bg
ou, fg
vous référez implicitement le travail le plus récent - dans mon cas, celui avec +
le ci-dessus. Ces travaux peuvent également (entre autres) être explicitement appelés % 1% 2 ou% 3 (le nombre en []
).
Une fg
commande non qualifiée n'affectera qu'un seul travail, le plus récent, vous pouvez donc vous tromper dans votre compréhension de la situation actuelle. Un travail en arrière-plan peut toujours écrire sur le terminal:
echo foo > /dev/tcp/127.0.0.1/10111
Cela peut dépendre de la façon dont le programme gère le terminal, ncat
fonctionne très bien pour l'écriture. Pour lire si les programmes arrêteront l'exécution, vous verrez un message "Arrêté". Le shell démarrera les processus et attendra qu'ils se terminent ou reçoivent un signal SIGTTIN ( nohup
c'est un moyen de contourner cela, tel quel disown
).
Vous pouvez mettre en arrière-plan un travail arrêté spécifique avec
$ bg %3
(dans mon cas, j'obtiendrai l'erreur bash: bg: job 3 already in background
)
Sinon, si un processus est au premier plan, à moins que le programme n'attrape SIGTSTP et ne fasse quelque chose de spécial, il est peu probable qu'il ait des problèmes avec un rapide Ctrl- Zet bg
. Les programmes réseau n'ont rien de spécial à cet égard, les connexions / données entrantes seront mises en mémoire tampon par le noyau (jusqu'à un certain point). Une connexion en streaming peut cependant avoir une pause observable.
Voir la section " JOB CONTROL " de la page de manuel bash pour plus de détails.