Processus Linux en arrière-plan - Arrêté dans les travaux ?

D'après ce que je peux comprendre.

Les tâches en arrière-plan ne peuvent pas lire le terminal de l'utilisateur. Lorsque l'on essaie de le faire, il sera suspendu jusqu'à ce que l'utilisateur le mette au premier plan et fournisse une entrée. "lire depuis le terminal de l'utilisateur" peut signifier soit essayer directement de lire depuis le terminal, soit modifier les paramètres du terminal.

Normalement, c'est ce que vous voulez, mais parfois les programmes lisent à partir du terminal et/ou modifient les paramètres du terminal non pas parce qu'ils ont besoin d'une entrée de l'utilisateur pour continuer, mais parce qu'ils veulent vérifier si l'utilisateur essaie de fournir une entrée.

http://curiousthing.org/sigttin-sigttou-deep-dive-linux contient les détails techniques sanglants.

Sous Linux et d'autres systèmes Unix, un travail qui s'exécute en arrière-plan, mais qui a toujours son stdin (ou std::cin ) associé à son terminal de contrôle (c'est-à-dire la fenêtre dans laquelle il a été exécuté) recevra un SIGTTIN signal, qui par défaut provoque l'arrêt complet du programme, en attendant que l'utilisateur le ramène au premier plan (fg %job ou similaire) pour permettre que les données soient effectivement transmises au programme. Pour éviter que le programme ne soit ainsi mis en pause, vous pouvez soit :

1. Assurez-vous que les programmes stdin channel n'est plus associé au terminal, soit en le redirigeant vers un fichier avec un contenu approprié pour le programme à saisir, soit vers /dev/null s'il n'a vraiment pas besoin d'entrée - par ex. myprogram < /dev/null & .
2. Quitter le terminal après avoir démarré le programme, ce qui provoquera l'association avec le stdin du programme s'en aller. Mais cela provoquera un SIGHUP à livrer au programme (ce qui signifie que le canal d'entrée/sortie a subi un "raccrochage") - cela provoque normalement la fin d'un programme, mais cela peut être évité en utilisant nohup - par exemple. nohup myprogram & .

Si vous souhaitez capturer la sortie du programme, c'est probablement la meilleure option, car elle empêche les deux signaux ci-dessus (ainsi que quelques autres) et enregistre la sortie pour que vous puissiez la regarder pour déterminer si il y a des problèmes avec l'exécution des programmes :

nohup myprogram < /dev/null > ${HOME}/myprogram.log 2>&1 &

Oui, il est vraiment arrêté et ne fonctionne plus en arrière-plan. Pour lui redonner vie tapez fg job_number