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


23

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.


pour être sûr, veuillez décrire étape par étape: je suppose que vous êtes ssh, démarrez une session tmux, détachez-vous de la session et fermez le shh: quand vous ssh à nouveau, vous n'avez aucun moyen de rejoindre la session tmix? c'est-à-dire que la session ne fonctionne plus?
Olivier Dulac

@OlivierDulac oui votre hypothèse est correcte. J'ai également modifié ma question pour inclure ces détails.
Gabriel Southern

comment fermez-vous la session ssh? et vous pouvez attacher une strace au pid de tmux et une autre au pid du sshd, pour voir si elle reçoit quelque chose lorsque vous fermez la connexion ssh (très verbeux, redirigez vers un fichier)
Olivier Dulac

@OlivierDulac merci pour la suggestion. J'ai mis à jour la question avec des informations de strace. Il semble que le processus du serveur tmux soit tué lorsque je termine la session ssh. Je ne pense pas que cela soit censé se produire, je dois donc comprendre pourquoi cela se produit.
Gabriel Southern

Démarrez tmux avec la journalisation détaillée activée et voyez si quelque chose est imprimé dans le journal lorsque vous vous déconnectez. En outre, quel est le TERM sur la machine distante dans et hors de tmux?
jasonwryan

Réponses:


16

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 sshd@.servicequi 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 ssh@.service.

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.


Y a-t-il des commentaires spécifiques de la part de l'électeur ou de la pêche à la traîne?
Pavel Šimerda

3
Merci pour la réponse détaillée. Le passage à sshd.service a résolu le problème.
Gabriel Southern

Je rencontre ce problème sur un système utilisant initplutôt que systemd. Mais c'est un peu différent de toute façon, voir ma question .
gerrit

5

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 .


1
Je dirais que vous ne voulez généralement pas utiliser cette fonctionnalité pour les connexions SSH si vos utilisateurs sont autorisés à exécuter des processus qui s'exécutent après la déconnexion. Ce n'est pas spécifique à screen ou tmux mais plutôt à SSH (avec tous les processus d'arrière-plan côté serveur).
Pavel Šimerda

2
@ PavelŠimerda oui, je pensais que cela était implicite, mais j'ai modifié l'article pour le rendre plus explicite maintenant.
mirabilos

3

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"


-bash: systemd-run: command not foundle Red Hat Enterprise Linux Server release 6.8 (Santiago).
gerrit

Est-ce que cela fonctionne quand je n'ai pas de root?
gerrit

1
J'ai remarqué que le comportement indésirable de destruction de tmux / écran ne se produit pas sur Ubuntu 18.04 LTS, seulement 16.04.
Seth

2

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


Est-ce que cela fonctionne quand je n'ai pas de root?
gerrit

Oui, c'est une solution valable. Mais vous voulez toujours résoudre le cas en redémarrant le service SSH sur la session SSH. :)
Pavel Šimerda

Les gars, dans le cas où vous utilisez OpenRC, j'ai fait un script tmux qui fait la même chose que le fichier de service mentionné dans ArchWiki
Megver83

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.