sesión de tmux eliminada al desconectarse de ssh


23

Resumen : estoy tratando de averiguar por qué mi sesión tmux muere cuando me desconecto de ssh

Detalles :

Tengo tmux instalado en un sistema Arch Linux. Cuando comienzo una sesión de tmux, puedo desconectarme y luego volver a adjuntarla mientras la sesión ssh está activa. Pero si termino mi sesión ssh, entonces la sesión tmux se mata.

Sé que este no es el comportamiento normal porque tengo otro sistema donde la sesión tmux continúa ejecutándose incluso si la sesión ssh finaliza y puedo conectarme a la sesión tmux después de establecer una nueva conexión ssh. El sistema que tiene un problema y el que funciona correctamente tiene configuraciones muy similares, por lo que no estoy seguro de qué verificar.

Estoy ejecutando tmux versión 1.9a. El sistema que tiene un problema (para el que tengo acceso de root) tiene una versión de kernel de Linux de 3.17.4-1 y el sistema que funciona correctamente tiene la versión de kernel 3.16.4-1-ARCH (no tengo root en eso sistema). Sin embargo, dudo que la versión del kernel sea la fuente del problema, esa es solo una diferencia que noté.

Pensé en preguntar si alguien ha visto un problema similar y sabe de una posible solución.

Los pasos precisos que conducen al problema son:

  1. ssh a la máquina
  2. corre tmuxpara iniciar tmux
  3. ctrl-B D para separar (en este punto podría volver a conectar con tmux attach
  4. cierre la sesión ssh (en este punto se cancela la sesión tmux, pude observar esto cuando inicié sesión como root en un terminal diferente)
  5. tmux attachme vuelvo a conectar con ssh y ejecuto y recibo el mensaje no sessionsy tmux lsdevuelve ejecutando failed to connect to server: Connection refused. Esto tiene sentido porque el servicio no se está ejecutando. Lo que no tiene sentido para mí es por qué se mata en el paso 4 cuando me desconecto de la sesión ssh.

datos de strace:

En respuesta a uno de los comentarios, utilicé strace para ver qué llamadas de sistemas realiza el proceso del servidor tmux. Parece que cuando salgo de mi sesión ssh (escribiendo exito con ctrl-d) que el proceso tmux está siendo eliminado. Aquí hay un fragmento de la parte final de la salida de 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 +++

Comparé esto con un sistema diferente donde tmux funciona correctamente y en ese sistema el proceso tmux continúa ejecutándose incluso después de salir. Entonces, la causa raíz parece ser que el proceso tmux está finalizando cuando cierro la sesión ssh. Tendré que pasar un tiempo resolviendo esto para entender por qué, pero pensé que actualizaría mi pregunta ya que la sugerencia de strace fue útil.


para estar seguro, describa paso a paso: supongo que ssh, iniciar una sesión tmux, desconectarse de la sesión y cerrar el shh: cuando ssh nuevamente, ¿no tiene ninguna forma de volver a unirse a la sesión tmix? es decir, la sesión ya no se está ejecutando?
Olivier Dulac

@ OlivierDulac sí, su suposición es correcta. También he editado mi pregunta para incluir estos detalles.
Gabriel Southern

¿Cómo cierras la sesión ssh? y podría adjuntar una secuencia al pid de tmux y otra al pid del sshd, para ver si recibe algo cuando cierra la conexión ssh (muy detallado, redirigir a un archivo)
Olivier Dulac

@ OlivierDulac gracias por la sugerencia. He actualizado la pregunta con información de strace. Parece que el proceso del servidor tmux se está matando cuando finalizo la sesión ssh. No creo que se suponga que esto suceda, así que necesito entender por qué está sucediendo.
Gabriel Southern

Inicie tmux con el registro detallado habilitado y vea si hay algo impreso en el registro cuando se desconecta. Además, ¿cuál es el TÉRMINO en la máquina remota dentro y fuera de tmux?
jasonwryan

Respuestas:


16

Teoría

Algunos sistemas init, incluido systemd, proporcionan una función para eliminar todos los procesos que pertenecen al servicio. El servicio generalmente inicia un proceso único que crea más procesos mediante bifurcación y esos procesos también pueden hacerlo. Todos estos procesos generalmente se consideran parte del servicio. En systemd esto se hace usando cgroups .

En systemd, todos los procesos que pertenecen a un servicio se eliminan cuando el servicio se detiene por defecto. El servidor SSH es obviamente parte del servicio. Cuando se conecta al servidor, el servidor SSH generalmente se bifurca y el nuevo proceso maneja su sesión SSH. Al bifurcar desde el proceso de sesión SSH o sus hijos, se inician otros procesos del lado del servidor, incluida su pantalla o tmux .

Killmode y activación de socket

El comportamiento predeterminado se puede cambiar usando la KillModedirectiva. El proyecto ascendente AFAIK no incluye ningún .servicearchivo, por lo que varían según la distribución. Por lo general, hay dos formas de habilitar SSH en su sistema. Uno es el clásico ssh.serviceque mantiene un demonio SSH de larga duración escuchando en la red. El otro es a través de la activación de socket manejada por el ssh.socketque a su vez comienza, sshd@.serviceque solo se ejecuta para una sola sesión SSH.

Soluciones

Si sus procesos se anulan al final de la sesión, es posible que esté utilizando la activación de socket y systemd lo anula cuando se da cuenta de que el proceso de sesión SSH salió. En ese caso hay dos soluciones. Una es evitar el uso de la activación del socket mediante el uso de en ssh.servicelugar de ssh.socket. El otro es establecer KillMode=processen la Servicesección de ssh@.service.

La KillMode=processconfiguración también puede ser útil con el clásico ssh.service, ya que evita matar el proceso de sesión SSH o la pantalla o los procesos tmux cuando el servidor se detiene o se reinicia.

Notas futuras

Esta respuesta aparentemente ganó un nivel de popularidad. Si bien funcionó para el OP, puede suceder que no funcione para alguien en el futuro debido al desarrollo o configuración de systemd-logind . Consulte la documentación sobre las sesiones de inicio de sesión si experimenta un comportamiento diferente de la descripción en esta respuesta.


¿Algún comentario específico del votante o solo trolling?
Pavel Šimerda

3
Gracias por la respuesta detallada. Cambiar a sshd.service solucionó el problema.
Gabriel Southern

Experimento este problema en un sistema que usa en initlugar de systemd. Pero es un poco diferente de todos modos, vea mi pregunta .
gerrit

5

¿Utiliza systemd con activación de socket para SSH?

Si es así, hay un problema conocido con eso . Según los defensores de systemd, esta es realmente una característica: systemd mata todos los procesos generados por una sesión cuando la sesión finaliza. (Puedo ver que es útil, pero en GNU screen, o tmux, en el caso, definitivamente no quieres eso ☺ ni en la mayoría de los otros casos en los que los usuarios pueden ejecutar procesos en segundo plano, por supuesto).

Si es así, intente cambiar de sshd.socketasshd.service .


1
Yo diría que, en general, no desea utilizar esa función para los inicios de sesión SSH si sus usuarios pueden ejecutar procesos que se ejecutan después de cerrar sesión. Eso no es específico para screen o tmux sino para SSH (con cualquier proceso en segundo plano en el lado del servidor).
Pavel Šimerda

2
@ PavelŠimerda sí, pensé que estaba implícito, pero edité la publicación para hacerlo más explícito ahora.
mirabilos

3

Estaba teniendo el mismo problema con tmux y screen en Ubuntu 16.04 (kde neon). Cuando se desconectó la sesión ssh, se finalizó screen / tmux.

Para resumir, systemd cambió su configuración predeterminada a killuserprocess = yes, así que después de salir de una sesión ssh, todos los procesos creados por él finalizarán.

Solución fácil (después de horas de intentarlo) ejecute screen / tmux usando este comando

Para la pantalla

systemd-run --scope --user screen

para Tmux

systemd-run --scope --user tmux

Puedes crear un alias para hacerlo más fácil

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


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

¿Funciona esto cuando no tengo root?
gerrit

1
Noté que el comportamiento no deseado de tmux / screen kill no ocurre en Ubuntu 18.04 LTS, solo 16.04.
Seth

2

Otra solución a esto, que no requiere pasar de sshd.socketa sshd.service, es iniciar el tmuxservidor como un servicio systemd [0]. De esta manera, el tmuxservidor ya se está ejecutando cuando ingresa SSH en el servidor, en lugar de engendrado por el tmuxcomando en SSH, por lo tanto, no se eliminará.

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


¿Funciona esto cuando no tengo root?
gerrit

Sí, esa es una solución válida. Pero aún desea resolver el caso reiniciando el servicio SSH sobre la sesión SSH. :)
Pavel Šimerda

Chicos, en caso de que utilicen OpenRC, hice un initscript tmux que hace lo mismo que el archivo de servicio mencionado en ArchWiki
Megver83

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.