Éditer pour 2016:
Cette période de questions précède 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 modifié par la mise KillUserProcesses=noen /etc/systemd/logind.confou contournée 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 plus longtemps que Linux n’existe.
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 l'observer avec la pstreecommande.
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 la plupart du temps, il commencera à envoyer SIGHUPles travaux en cours qui lui sont associés avant de se 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 propres, le signal sera également transmis.
Les processus qui survivent à un raccrochage du terminal de contrôle sont ceux qui se sont dissociés d'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 une nohupcommande préfixée . (c'est-à-dire "ne raccrochez pas"). Les démons interprètent le signal HUP différemment. Comme ils ne possèdent pas de terminal de contrôle et ne reçoivent pas automatiquement un signal HUP, celui-ci est réaffecté 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 screensont les plus populaires; La syntaxe pour les utiliser va au-delà de la portée de votre question, mais elles méritent d'être explorées.
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 le serveur, et il existe généralement deux types: le niveau de l'application et le protocole TCP (c.
SO_KEEPALIVE-à-d.). 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 également pour effet secondaire 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 une partie a décidé que le socket est mort, les effets sont généralement immédiats: le processus sshd envoie HUPet se termine automatiquement (comme décrit précédemment), ou le client informe l'utilisateur du problème détecté. Il convient de 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 ne se produit que lorsque le serveur l’ a remarqué.
screen, essayez reptyr .