☰

알 수 없는 pts에서 tmux 세션이 손실되었습니다. 원인과 가능한 해결 방법은 무엇입니까?

tag-icon • tag-icon process tmux session
알 수 없는 pts에서 tmux 세션이 손실되었습니다. 원인과 가능한 해결 방법은 무엇입니까?

Python 웹 애플리케이션을 확인하기 위해 장기 실행 tmux 세션에 다시 연결하려고 했습니다. 그러나 tmux attach실행 중인 세션이 없다고 주장하고 프로세스(첫 번째 줄) ps를 표시 tmux하지만 숫자 대신 물음표가 표시됩니다 pts.

이것이 의미하는 바는 -- 이 tmux 세션이 영구적으로 손실되었다는 것이며, 그 원인은 무엇입니까? tmux 세션에서 생성되고 pts/19(두 번째 줄) 에서 실행되는 Python 프로세스의 현재 상태를 볼 수 있는 방법이 여전히 있습니까 ?

[mhermans@web314 ~]$ ps -ef | grep mhermans
mhermans 16709     1  0 Mar04 ?        00:26:32 tmux
mhermans  8526 16710  0 Mar04 pts/19   00:20:04 python2.7 webapp.py
root      9985  6671  0 10:18 ?        00:00:00 sshd: mhermans [priv]
mhermans 10028  9985  0 10:18 ?        00:00:00 sshd: mhermans@pts/16
mhermans 10030 10028  0 10:18 pts/16   00:00:00 -bash
mhermans 16247 10030  6 10:28 pts/16   00:00:00 ps -ef
mhermans 16276 10030  0 10:28 pts/16   00:00:00 grep mhermans
mhermans 16710 16709  0 Mar04 pts/19   00:00:00 -bash
mhermans 16777 16709  0 Mar04 pts/21   00:00:00 -bash

답변1

솔루션 제공웹팩션 지원:

프로세스가 계속 실행 중이었기 때문에 삭제된 소켓이 문제였으며 아마도 제거된 tmp 디렉터리로 인해 발생했을 수 있습니다.

지도 에 따르면 tmux:

소켓이 실수로 제거된 경우 SIGUSR1 신호가 다시 생성되기 위해 tmux 서버 프로세스로 전송될 수 있습니다.

따라서 신호를 보내고 연결하는 작업은 다음과 같습니다.

killall -s SIGUSR1 tmux
tmux attach

답변2

터미널 부재는 분리된 세션의 신호입니다. 모든 tmux세션 이름은 다음과 같이 찾을 수 있습니다.

ls $TMP/tmux-$(id -u)또는ls /var/run/tmux/tmux-$(id -u)

— 이것은 배포판에 따라 다릅니다. 배포판에 거의 독립적이고 더 하드코어한 경우는 다음과 같습니다.

lsof -n -p 16709 -a -U

16709목록에서 tmux의 PID는 어디에 있습니까?

답변3

이것이 방법이다이 이전 답변은 여기에 있습니다.도와줬어요 (와우!) 해결하려고 했는데정확히하나의 Tmux에 연결되어 있는 상황은 에서 볼 수 있습니다 tmux ls.하지만에서는 ps나도 볼 수 있어또 다른tmux는 목록에 없으므로 tmux ls이름을 사용하여 연결할 수 없습니다(tmux attach -t myOldbas)

자세한 내용은 다음과 같습니다. 프로세스:

71358     1849  9617  0 Sep04 pts/29   00:00:00 /bin/bash
71358     2528  9617  0 Aug31 pts/25   00:00:00 /bin/bash
71358     9617     1  0 Aug31 ?        00:08:55 tmux new -s myOld
71358     9618  9617  0 Aug31 pts/20   00:00:00 /bin/bash
71358    20199 33189  0 Sep16 pts/27   00:00:00 vim log
71358    20415 32257  0 Sep16 pts/30   00:00:00 /bin/bash
71358    24735 32257  0 Sep16 pts/33   00:00:00 /bin/bash
71358    32257     1  0 Sep16 ?        00:04:02 tmux new -s myses

지금,lsof 비트가 나에게 정말 도움이 되었어요--당신이 그것을 할 때두 프로세스 모두, 내 경우에는 32257(내가 볼 수 있는 것) 및 9617(이전 것)

/usr/sbin/lsof -n -p 32257 -a -U
COMMAND   PID             USER   FD   TYPE             DEVICE SIZE/OFF      NODE NAME
..
tmux    32257 uzer.buzer          7u  unix 0xffff881ff0c73480      0t0 995795763 /tmp/uzer.buzer/tmux-71358/default

그러나 이전 PID를 사용했을 때 다음을 보았습니다.

/usr/sbin/lsof -n -p 9617 -a -U

tmux    9617 uzer.buzer          7u  unix 0xffff881ff0c73480      0t0 995795763 /tmp/tmux-71358/default

알아채다,마지막 소켓 경로는 어떻게 다른가요? 운 좋게도 그게 내가 필요한 전부였고 명시적인 소켓을 사용하여 연결 명령을 실행했습니다.

tmux -S /tmp/tmux-71358/default at

그리고 나는 안에 있었다!!

답변4

나중에 이 스레드를 접하게 되는 사람들을 위해;

sudo를 사용하여 스크립트 등을 실행하는 경우 tmuxsudo를 사용한 사용자가 아닌 루트 아래에 세션이 나열됩니다. sudo 이후의 작업은 루트에서 수행되기 때문입니다.

이 문제를 해결하려면 루트로 sudo tmux a또는 를 사용하여 tmuxtmux 세션 제어권을 다시 얻으십시오.

관련 정보