Question Être déconnecté d'une session SSH tue-t-il vos programmes?


Donc, disons que je suis déconnecté d'une session SSH après avoir commencé rsync ou cp ou toute autre commande qui peut être longue. Cette commande continue-t-elle à fonctionner jusqu'à ce qu'elle soit terminée après ma déconnexion ou est-elle simplement mise à mort?

Toujours demandé cela.


75
2018-01-06 03:09


origine


Je veux juste ajouter à ce qui a été dit plus haut que, si vous vous trouvez dans une situation où vous devez mettre un processus déjà en cours dans screenessayer reptyr. - a sad dude


Réponses:


Éditer pour 2016:

Ce Q & A est antérieur à la débâcle de Systemd v230. Depuis Systemd v230, la nouvelle valeur par défaut consiste à tuer tous les enfants d'une session de connexion qui se termine, quelles que soient les précautions historiquement valables prises pour empêcher cela. Le comportement peut être changé en définissant KillUserProcesses=no dans /etc/systemd/logind.conf, ou contourné en utilisant les mécanismes spécifiques à systemd pour démarrer un démon dans l’espace utilisateur. Ces mécanismes sortent du cadre de cette question.

Le texte ci-dessous décrit la manière dont les choses ont toujours fonctionné dans UNIX Designspace depuis bien plus longtemps que Linux n’existait.


Ils seront tués, mais pas nécessairement immédiatement. Cela dépend du temps que prend le démon SSH pour décider que votre connexion est morte. Ce qui suit est une explication plus longue qui vous aidera à comprendre comment cela fonctionne réellement.

Lorsque vous vous êtes connecté, le démon SSH vous a attribué un pseudo-terminal et l'a connecté au shell de connexion configuré de votre utilisateur. Ceci est appelé le terminal de contrôle. Tous les programmes que vous démarrez normalement à ce stade, quel que soit le nombre de couches de coquilles profondes, retrouveront leur origine dans cette coquille. Vous pouvez observer cela avec le pstree commander.

Lorsque le processus démon SSH associé à votre connexion décide que votre connexion est morte, il envoie un signal de raccrochage (SIGHUP) au shell de connexion. Cela informe le shell que vous avez disparu et qu'il devrait commencer à se nettoyer. Ce qui se passe à ce stade est spécifique au shell (recherchez "HUP" dans la page de documentation), mais pour la plupart, il commencera à envoyer SIGHUP d’exécuter les tâches qui lui sont associées avant de terminer. Chacun de ces processus, à son tour, fera ce qu'il est configuré pour faire à la réception de ce signal. Habituellement, cela signifie la fin. Si ces emplois ont des emplois qui leur sont propres, le signal sera également transmis.

Les processus qui survivent à un blocage du terminal de contrôle sont ceux qui se sont dissociés de l’avoir un terminal (processus de démon que vous avez démarrés à l’intérieur de celui-ci) ou ceux qui ont été appelés avec un préfixe. nohup commander. (c.-à-d. "ne raccrochez pas"). Les démons interprètent le signal HUP différemment. dans la mesure où ils ne disposent pas de terminal de contrôle et ne reçoivent pas automatiquement un signal HUP, celui-ci est réutilisé sous la forme d'une demande manuelle de l'administrateur pour recharger la configuration. Ironiquement, cela signifie que la plupart des administrateurs n’apprennent l’utilisation du "blocage" de ce signal pour les non-démons que beaucoup plus tard. C'est pourquoi vous lisez ceci!

Les multiplexeurs de terminaux sont un moyen courant de garder votre environnement shell intact entre les déconnexions. Ils vous permettent de vous détacher de vos processus shell de manière à pouvoir vous reconnecter ultérieurement, que cette déconnexion soit accidentelle ou délibérée. tmuxet screen sont les plus populaires; La syntaxe pour les utiliser va au-delà de la portée de votre question, mais elle mérite d’être examinée.


Il a été demandé que je précise dans combien de temps le démon SSH décide que votre connexion est morte. Il s'agit d'un comportement spécifique à chaque implémentation d'un démon SSH, mais vous pouvez compter sur chacune d'entre elles pour se terminer lorsque l'un ou l'autre côté réinitialise la connexion TCP. Cela se produira rapidement si le serveur tente d'écrire sur le socket et si les paquets TCP ne sont pas reconnus, ou lentement si rien ne tente d'écrire sur le PTY.

Dans ce contexte particulier, les facteurs les plus susceptibles de déclencher une écriture sont les suivants:

  • Un processus (généralement celui du premier plan) qui tente d’écrire sur le PTY côté serveur. (serveur-> client)
  • L'utilisateur essayant d'écrire sur le PTY côté client. (client-> serveur)
  • Keepalives de toute sorte. Celles-ci ne sont généralement pas activées par défaut, que ce soit par le client ou par le serveur. Il existe généralement deux types: le niveau de l'application et le protocole TCP (c'est-à-dire SO_KEEPALIVE). Keepalives revient au serveur ou au client qui envoie rarement des paquets à l’autre côté, même lorsque rien n’aurait autrement une raison d’écrire dans le socket. Bien que cela ait généralement pour but de contourner les pare-feu qui expirent trop rapidement les connexions, cela a pour effet supplémentaire de faire en sorte que l'expéditeur remarque que l'autre côté ne répond pas plus rapidement.

Les règles habituelles pour les sessions TCP s'appliquent ici: en cas d'interruption de la connectivité entre le client et le serveur, mais si aucun des deux camps ne tente d'envoyer un paquet pendant le problème, la connexion survivra à condition que les deux côtés réagissent ensuite et reçoivent le protocole TCP attendu. numéros de séquence.

Si un côté a décidé que le socket est mort, les effets sont généralement immédiats: le processus sshd enverra HUP et se terminer automatiquement (comme décrit précédemment), sinon le client avertira l'utilisateur du problème détecté. Il est à noter que le fait que l'une des parties pense que l'autre est mort ne signifie pas que l'autre a été averti de cela. Le côté orphelin de la connexion reste généralement ouvert jusqu'à ce qu'il tente d'écrire et expire ou qu'il reçoive une réinitialisation TCP de l'autre côté. (si la connectivité était disponible à ce moment-là) Le nettoyage décrit dans cette réponse n’a lieu que lorsque le serveur a remarqué.


108
2018-01-06 04:36



J'ajouterais également la commande 'dtach' à cette liste - c'est un peu l'opposé de screen / tmux en ce sens qu'elle vous permet d'attacher plusieurs terminaux à une seule session et qu'elle est également idéale pour prolonger une session, bien que ce ne soit pas le cas. fournir aucun moyen de rejouer l'histoire récente. - fluffy
dtach l'URL est ici: dtach.sourceforge.net - slm
excellente explication. Je me sens déjà plus linuxey! - fregas
De plus, bien que cela ne fasse pas techniquement partie de votre réponse, voici une anecdote intéressante: vous pouvez utiliser kill -HUP en tant que racine pour forcer le terminal de quelqu'un à raccrocher. Vous ne devriez pas faire cela sans bonne raison. Je profite au maximum de mon kilométrage lorsque les utilisateurs laissent les shell en cours d'exécution pendant la maintenance et que je dois démonter un système de fichiers que leur shell garde ouvert. Si l'utilisateur est connecté mais qu'il est à l'arrêt, envoyez le signal à son processus sshd. Sinon, s'il fonctionne à l'intérieur d'un multiplexeur de terminal, envoyez-le au shell que vous souhaitez arrêter. Ne raccrochez que la coquille pour vous empêcher de travailler! - Andrew B
@ AndrewB, pourriez-vous s'il vous plaît expliquer comment "le processus du démon SSH ... décide que votre connexion est morte"? Et comment puis-je savoir si le démon SSH pense / sait que la connexion (quelle) est morte ou non? - Xiao Peng - ZenUML.com


Comme d'autres l'ont mentionné, une fois que vous vous êtes déconnecté de ssh, tout ce qui s'y trouve est parti.

Comme @ Michael Hampton et d'autres ont mentionné que vous pouvez utiliser des outils tels que tmux ou screen déconnecter / reconnecter aux terminaux sans perdre leur contenu (processus enfants, par exemple).

De plus, vous pouvez mettre un processus en arrière-plan à l'aide d'une esperluette & puis utilisez la commande disown pour les dissocier du shell actuel.

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%

21
2018-01-06 05:27



Est-il possible de rattacher une session de terminal à un disownprocessus ed? - Fake Name
Oui. Voir cette question U & L pour plus de détails: unix.stackexchange.com/questions/4034/… - slm


Non, tous les programmes encore attachés au terminal, et non placés en arrière-plan avec quelque chose comme nohup, serait tué.

C’est pourquoi il existe des solutions de terminaux virtuels telles que tmux et le plus vieux screen qui créent des sessions qui continuent à s'exécuter même si vous êtes déconnecté et auxquelles vous pouvez vous reconnecter ultérieurement.


11
2018-01-06 03:16