Vérifier la commande de désabonnement


10

J'ai émis la ^z; bg; disownséquence afin de me permettre de fermer une session ssh dans laquelle j'exécute un processus de longue durée super important. Ce processus écrit la sortie d'état dans stderr, et il a continué à le faire même après avoir été détaché (vérifié avec lsof, le stderr fd est ouvert pour r / w).

Existe-t-il un moyen de déterminer que le processus a bien été renié (ne récupérera pas SIGHUP si le shell en récupère un)?


1
Je me demande si cela doit aller sur unix.stackexchange.com
Rilindo

2
Juste curieux, pourquoi pas: $ PROCESS 1 >> / root / std.out 2 >> / root / err.out &
Avery Payne

Réponses:


12

Dans Bash, la disowncommande émise d'elle-même supprimera les processus en arrière-plan (via bgou &) de la table de travaux active et les marquera pour ne pas recevoir de SIGHUP à la déconnexion.

Vous pouvez également passer un ou plusieurs travaux à désavouer, comme disown 1 3. L' disown -hindicateur est utile si vous souhaitez conserver les travaux dans la table, mais toujours pas SIGHUP à la déconnexion.

Vous pouvez afficher la table des travaux en exécutant la jobscommande. Après un fond réussi, cela se verra [1]+ command &. Après avoir désavoué un travail, il ne devrait plus s'afficher dans la table des travaux et ne plus être supprimé à la déconnexion. Vous pouvez toujours le processus par l' intermédiaire ps ux, topet d' autres utilitaires de visualisation processus.

Une fois qu'une tâche a été supprimée, vous pouvez attendre qu'elle se termine naturellement ou envoyer un signal via killle PID pour l'arrêter.

Parce que Bash supprime simplement le travail de la liste des travaux en cours pour terminer et que les poignées de fichier vers la sortie standard et la sortie de votre terminal sont toujours ouvertes, vous continuerez à recevoir la sortie du travail jusqu'à ce que votre terminal soit fermé (lorsque vous vous déconnectez) .

Exemples:

# we start a command in the background
$ cat /dev/urandom > test &
[1] 18533

# we see our command is still running
$ jobs
[1]+  Running                 cat /dev/urandom > test &

# we disown the backgrounded job
$ disown 1

# notice it is no longer in the job table
$ jobs

Je n'utilise généralement que disownsi j'exécute une commande potentiellement longue comme un rsyncou cpet décide ensuite que je dois me déconnecter sans y mettre fin. Si vous savez que vous allez exécuter une commande et vous déconnecter, vous pouvez capturer la sortie en canalisant ou en l' teeintégrant dans un fichier, en l'exécutant avec nohupou en l'exécutant screen(ce qui vous permet de reprendre la propriété de la commande / de terminer ensuite ).

Exemples:

# capture stdout and stderr to separate logs
cat /dev/urandom >stdout.log 2>stderr.log

# capture stdout and stderr to the same log, and display to stdout as well
cat /dev/urandom 2>&1 | tee output.log

# run a command under nohup (doesn't require a disown or job control support)
nohup cat /dev/urandom </dev/null

1
+1 Informatif et avec des exemples. Agréable!
Andy Smith

Commentaire très informatif; dites-vous qu'il n'est pas possible de vérifier le détachement d'un processus (en plus de noter qu'il n'existe plus dans la table des travaux)?
mikewaters

1
lorsque vous exécutez detachun travail en arrière-plan, il va être détaché :) il n'y a pas vraiment de terrain d'entente où l'exécuter sur un processus en arrière-plan ne fera rien. la vérification jobsvérifie simplement que vous n'avez pas essayé de détacher un processus arrêté ou quelque chose.
lunixbochs
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.