session tmux tuée lors de la déconnexion de ssh

Résumé : j'essaie de comprendre pourquoi ma session tmux meurt lorsque je me déconnecte de ssh

Détails :

J'ai installé tmux sur un système Arch Linux. Lorsque je démarre une session tmux, je peux m'en détacher puis la rattacher pendant que la session ssh est active. Mais si je termine ma session ssh, la session tmux est tuée.

Je sais que ce n'est pas le comportement normal car j'ai un autre système où la session tmux continue de fonctionner même si la session ssh est terminée et je peux me connecter à la session tmux après avoir établi une nouvelle connexion ssh. Le système qui a un problème et celui qui fonctionne correctement ont des configurations très similaires, donc je ne sais pas quoi vérifier.

J'utilise la version 1.9a de tmux. Le système qui a un problème (pour lequel j'ai un accès root) a une version du noyau Linux de 3.17.4-1 et le système qui fonctionne correctement a la version du noyau 3.16.4-1-ARCH (je n'ai pas de racine sur ce système). Je doute que la version du noyau soit la source du problème, c'est juste une différence que j'ai remarquée.

J'ai pensé que je demanderais à voir si quelqu'un a vu un problème similaire et connaît une solution possible.

Les étapes précises qui conduisent au problème sont les suivantes:

1. ssh à usiner
2. courir tmuxpour démarrer tmux
3. ctrl-B D à détacher (à ce stade, je pourrais rattacher avec tmux attach
4. fermer la session ssh (à ce stade, la session tmux est interrompue, j'ai pu l'observer lorsque je suis connecté en tant que root dans un autre terminal)
5. reconnectez-vous avec ssh et exécutez tmux attachet je reçois le message no sessionset les tmux lsretours en cours d'exécution failed to connect to server: Connection refused. Cela a du sens car le service n'est pas en cours d'exécution. Ce qui n'a pas de sens pour moi, c'est pourquoi il est tué à l'étape 4 lorsque je me déconnecte de la session ssh.

données strace:

En réponse à l'un des commentaires, j'ai utilisé strace pour voir ce que les systèmes appellent le processus du serveur tmux. Il semble que lorsque je quitte ma session ssh (en tapant exitou avec ctrl-d), le processus tmux est en cours de suppression. Voici un extrait de la dernière partie de la sortie strace.

poll([{fd=4, events=POLLIN}, {fd=11, events=POLLIN}, {fd=6, events=POLLIN}], 3, 424) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
sendto(3, "\17", 1, 0, NULL, 0)         = 1
+++ killed by SIGKILL +++

J'ai comparé cela à un système différent où tmux fonctionne correctement et sur ce système, le processus tmux continue de fonctionner même après ma sortie. Ainsi, la cause première semble être que le processus tmux se termine lorsque je ferme la session ssh. Je vais devoir passer un peu de temps à résoudre ce problème pour comprendre pourquoi, mais j'ai pensé que je mettrais à jour ma question car la suggestion de strace était utile.

Théorie

Certains systèmes d'initialisation, y compris systemd, fournissent une fonctionnalité pour tuer tous les processus appartenant au service. Le service démarre généralement un processus unique qui crée plus de processus par forking et ces processus peuvent également le faire. Tous ces processus sont généralement considérés comme faisant partie du service. Dans systemd, cela se fait à l'aide de cgroups .

Dans systemd, tous les processus appartenant à un service sont tués lorsque le service est arrêté par défaut. Le serveur SSH fait évidemment partie du service. Lorsque vous vous connectez au serveur, le serveur SSH bifurque généralement et le nouveau processus gère votre session SSH. En forçant à partir du processus de session SSH ou de ses enfants, d'autres processus côté serveur sont démarrés, y compris votre écran ou tmux .

Killmode et activation de socket

Le comportement par défaut peut être modifié à l'aide de la KillModedirective. Le projet en amont ne contient aucun .servicefichier AFAIK et ceux-ci varient donc selon la distribution. Il existe généralement deux façons d'activer SSH sur votre système. L'un est le classique ssh.servicequi maintient un démon SSH de longue durée à l'écoute sur le réseau. L'autre est via l'activation de socket gérée par celui ssh.socketqui à son tour démarre [email protected]qui ne s'exécute que pour une seule session SSH.

Solutions

Si vos processus sont tués à la fin de la session, il est possible que vous utilisiez l'activation de socket et il soit tué par systemd lorsqu'il remarque que le processus de session SSH s'est terminé. Dans ce cas, il existe deux solutions. L'une consiste à éviter d'utiliser l'activation de socket en utilisant ssh.serviceau lieu de ssh.socket. L'autre consiste à définir KillMode=processdans la Servicesection de [email protected].

Le KillMode=processparamètre peut également être utile avec le classique ssh.service, car il évite de tuer le processus de session SSH ou les processus screen ou tmux lorsque le serveur est arrêté ou redémarré.

Notes futures

Cette réponse a apparemment gagné en popularité. Bien que cela ait fonctionné pour l'OP, il pourrait arriver que cela ne fonctionne pas pour quelqu'un à l'avenir en raison du développement ou de la configuration de systemd-logind . Veuillez consulter la documentation sur les sessions de déconnexion si vous rencontrez un comportement différent de la description de cette réponse.

Utilisez-vous systemd avec l'activation de socket pour SSH?

Si oui, il y a un problème connu avec cela . Selon les partisans de systemd, il s'agit en fait d'une fonctionnalité - systemd tue tous les processus générés par une session lorsque la session se termine. (Je peux voir que cela est utile, mais dans le GNU screen, ou tmux, dans le cas, vous ne voulez certainement pas cela, ni dans la plupart des autres cas où les utilisateurs peuvent exécuter des processus d'arrière-plan, bien sûr.)

Si tel est le cas, essayez de passer de sshd.socketàsshd.service .

J'avais le même problème avec tmux et screen sur Ubuntu 16.04 (kde neon). Lorsque la session ssh a été déconnectée, screen / tmux a été arrêté.

Pour faire court, systemd a changé son paramètre par défaut en killuserprocess = yes donc après avoir quitté une session ssh, tous les processus créés par celle-ci seront interrompus.

Solution facile (après des heures d'essais) exécutez screen / tmux en utilisant cette commande

Pour écran

systemd-run --scope --user screen

pour Tmux

systemd-run --scope --user tmux

Vous pouvez créer un alias pour le rendre plus facile

alias tmux= "systemd-run --scope --user tmux"

Une autre solution à cela, qui ne nécessite pas de passer de sshd.socketà sshd.service, est de démarrer le tmuxserveur en tant que service systemd [0]. De cette façon, le tmuxserveur est déjà en cours d'exécution lorsque vous SSH sur le serveur, au lieu d'être généré par la tmuxcommande dans SSH, ne sera donc pas tué.

[0] https://wiki.archlinux.org/index.php/tmux#Autostart_with_systemd

La meilleure réponse que j'ai trouvée, IMO, est donnée à Empêcher la déconnexion de tuer la session tmux :

Cette «fonctionnalité» existait systemdauparavant, mais les systemddéveloppeurs ont décidé d'effectuer une modification par défaut , pour activer le paramètre de fin des processus enfants lors de la déconnexion d'une session.

Vous pouvez rétablir ce paramètre dans votre logind.conf( /etc/systemd/logind.conf):

KillUserProcesses=no