Quand jexécute ces quatre commandes sur Xubuntu 16.04, que ce soit localement ou via ssh, elles semblent toutes faire exactement la même chose:
export DISPLAY=:0.0 #not necessary unless you have logged in over ssh instead of starting a terminal locally -
gedit & -
gedit & disown -
nohup gedit -
nohup gedit & disown
Je ne « t obtenir la différence entre gedit & et gedit & disown car si je tue le terminal parent ou me déconnecte dune session ssh, il semblerait que gedit est « désavoué » dans les deux scénarios.
Comme pour deux et trois, la seule différence que je vois est que la sortie de la commande est enregistrée dans un fichier séparé et continuera à être enregistrée dans ce journal séparé même si la session shell originale qui a engendré le processus bg est tuée.
Pour ce qui est des trois et quatre, je continue à lire quil y a une différence technique, mais je ne comprends pas du tout pourquoi vous préféreriez lun sur lautre.
Lequel dois-je utiliser? Jai vu les quatre commandes utilisées dans les didacticiels et Q & Comme, et malgré quelques très bonnes réponses décrivant les différences techniques entre nohup et disown, je ne peux pas sembler obtenir une recommandation claire (sauf peut-être à des fins de journalisation ou de compatibilité avec le shell) pour laquelle je devrais utiliser.
Commentaires
- Vous avez besoin de & dans tous les cas où vous voulez continuer dans le shell (et le programme ne se fourche pas). Vous naurez peut-être pas besoin de nohup pour les programmes qui ferment les descripteurs de fichiers et se dissocient (cela. Gibt est vrai pour la plupart des applications GUI). Vous pouvez utiliser disown après coup (si vous oubliez nohup) et comme écrit auparavant, les applications GUI nen ont pas besoin.
Answer
Quand jai besoin dexécuter un script qui fonctionnera pendant longtemps , et je » m sur une session ssh, je veux soit:
-
La tâche doit continuer même lorsque le réseau est interrompu ou lorsque jemballe mon ordinateur portable et que je pars .
a. La tâche peut se terminer sans intervention interactive de ma part.
nohup do_my_stuff &b. La tâche peut nécessiter quelque chose de ma part sur stdin .
man tmux history -w tmux do_my_stuff -
Le processus darrière-plan améliore en quelque sorte ma session actuelle et devrait mourir avec la session. Une rareté.
enhance_my_session >>/tmp/enhance.$$.log 2>&1 & -
Je veux que la chose crache des journaux au hasard lors de ma session ssh. Attendez, quoi? Non, je ne voudrais jamais cela. Merci vous
disown. -
Une autre chose que je ne veux jamais: convertir le processus vers un démon entièrement détaché, mais évitez de le démarrer automatiquement au prochain démarrage. Je ne voudrais jamais cela car je ne peux pas prédire quand le système redémarrera et qui le redémarrera.
Réponse
En général, je fais simplement ce qui suit:
-
myprog &si je veux simplement exécuter quelque chose en arrière-plan à partir de mon shell de connexion actuel. Cela me convient 99% du temps … -
nohup myprog > /my/path/output.txt &si je démarre quelque chose depuis le shell, mais que je veux déconnectez-vous ensuite (peut-être pendant que la tâche darrière-plan est toujours en cours).
Réponse
Vous doit distinguer la sortie du shell de lannulation du terminal.
- Le shell tue tous les jobs connus (mais pas leurs enfants) lorsquil reçoit un signal dabandon.
- Le terminal tue tout ce dont il était le terminal de contrôle.
En général, la meilleure solution (au niveau de lutilisateur) IMHO est screen.
Si votre tâche est plutôt liée au système quà lutilisateur, vous pouvez en faire un service systemd à la place que vous démarrez manuellement.