Qu'arrive-t-il à une opération continue si nous faisons ssh puis nous déconnectons?

Je déplace un répertoire vers un autre à l'aide de la commande mv.

Cependant, j'ai été obligé d'arrêter mon ordinateur, ce qui signifie perdre la connexion au serveur.

Qu'advient-il de la commande mv?

Remarque: Après m'être reconnecté, j'ai vu que tous les fichiers ont été correctement déplacés, même si j'étais sûr qu'ils n'avaient pas été déplacés lorsque j'ai fermé la connexion. Il semble que mv ait continué de fonctionner.

C'est moi ssh à centosh machine dans le serveur cloud steadfast.net.

Si a mvété démarré comme:

ssh host mv x y

Puis mvrecevra un SIGPIPE (et mourra) s'il essaie d'écrire quoi que ce soit sur stdout ou stderr (comme un message d'erreur).

Si vous avez commencé une session interactive comme:

ssh host

Et a commencé à mvpartir du shell interactif là-bas, lorsque le côté maître du pseudo-terminal démarré par sshdsera fermé (à la sshfermeture de la connexion TCP à la sortie), le chef de la session associée au côté esclave du pseudo-terminal, qui est le shell interactif distant, recevra un signal SIGHUP (raccrocher).

À la réception de ce signal, les shells (sauf si vous en avez émis un trap '' HUP) transmettent généralement ce signal à tous les processus dans les tâches qu'ils ont démarrées, sauf si vous leur avez explicitement dit de ne pas le faire (comme avec disownou avec &|dans certains shells).

D'autres processus (comme mv) mourront généralement lors de la réception de ce signal, sauf si on leur a dit de l'ignorer (en l'utilisant nohupou si leur parent l'a ignoré).

Si vous avez émis un:

trap '' HUP

Ensuite, tous les travaux ont commencé après qu'il en héritera et ignorera SIGHUP.

Le shell ne mourra pas du signal SIGHUP envoyé lors de la déconnexion mais se fermera à l'invite suivante, car son stdin est parti. À la sortie, certains obus envoient SIGHUP à leurs emplois (non reniés). Ceux qui ont commencé après l' trap '' HUPignoreront, les autres mourront.

En bref, dans ce cas, à moins que vous n'ayez pris des précautions préalables pour que cela ne se produise pas, vous mvmourrez.

Pour éviter cela la prochaine fois, si vous utilisez tcsh, zshou bash, avant d'arrêter la machine, appuyez sur Ctrl-Zpour suspendre mv, entrez bgpour la reprendre en arrière-plan et disownpour la désactiver .

Ou vous pouvez utiliser screenou tmux. Lors d'un SIGHUP, ceux-ci se détacheront simplement de leur terminal hôte maintenant disparu, mais les applications exécutées dans le terminal qu'il émule continueront de fonctionner sans tête et vous pouvez rattacher la session à un autre terminal plus tard pour voir comment cela mvs'est passé.

Ou utilisez-le nohup mvpour vous mvimmuniser contre SIGHUP et voir sa sortie et ses erreurs aller dans un nohup.outfichier que vous pourrez vérifier plus tard.

Maintenant, je ne connais pas votre fournisseur d'hébergement spécifique, mais avec certains, lorsque vous entrez sshdans l'instance, vous ne démarrez pas de sessions shell là-bas, mais vous vous attachez plutôt à la console, c'est-à-dire à une session qui a déjà été démarrée et lorsque vous quittez, vous ne mettez pas fin à cette session, il vous suffit de vous en détacher. Ainsi, l'obus n'est pas tué, non plus mv. Si tel est le cas, vous remarquerez que l' psexécution à partir de là vous donnera la même chose pidpour votre shell sur deux sshsessions distinctes .