Ich habe versucht, eine Verbindung zu einer lang laufenden Tmux-Sitzung wiederherzustellen, um eine Python-Webanwendung zu überprüfen. Es tmux attach
wird jedoch behauptet, dass keine Sitzung ausgeführt wird, und ps
es wird ein tmux
Prozess angezeigt (erste Zeile), jedoch mit einem Fragezeichen anstelle der pts
Nummer.
Was bedeutet das – ist diese Tmux-Sitzung dauerhaft verloren gegangen und was könnte die Ursache dafür sein? Gibt es noch eine Möglichkeit, den aktuellen Status des Python-Prozesses anzuzeigen, der in der Tmux-Sitzung gestartet wurde und in pts/19
(zweite Zeile) ausgeführt wird?
[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
Antwort1
Lösung mit freundlicher Genehmigung derWebfaction-Unterstützung:
Da der Prozess noch lief, lag das Problem an einem gelöschten Socket, möglicherweise verursacht durch ein bereinigtes temporäres Verzeichnis.
Laut tmux
Karte:
Wenn der Socket versehentlich entfernt wird, kann das SIGUSR1-Signal an den Tmux-Serverprozess gesendet werden, um ihn neu zu erstellen.
So funktioniert das Senden des Signals und das Anhängen:
killall -s SIGUSR1 tmux
tmux attach
Antwort2
Das Fehlen eines Terminals ist ein Zeichen für eine getrennte Sitzung. Und alle Ihre tmux
Sitzungsnamen können wie folgt gefunden werden:
ls $TMP/tmux-$(id -u)
oderls /var/run/tmux/tmux-$(id -u)
— das ist irgendwie distributionsabhängig. Fast distributionsunabhängig (und Hardcore-mäßiger) wäre:
lsof -n -p 16709 -a -U
wo 16709
ist die PID von tmux in Ihrer Auflistung.
Antwort3
Das ist wiediese frühere Antwort hierhat mir geholfen (wow!). Ich habe versucht zu lösengenaudie Situation, in der ich an einen Tmux angeschlossen bin - was ich in sehen kann tmux ls
,Aberin ps
, ich kann auch sehenein anderertmux, das nicht aufgeführt ist, tmux ls
daher kann ich keine Verbindung über seinen Namen herstellen (tmux attach -t myOldbas)
Hier sind alle Einzelheiten. Prozesse:
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
Jetzt,das LSOF-Bit hat mir wirklich geholfen--wenn du es tust fürbeide Prozesse, in meinem Fall 32257 (die, die ich sehen kann) und 9617 (die alte)
/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
Als ich jedoch das alte PID verwendete, sah ich Folgendes
/usr/sbin/lsof -n -p 9617 -a -U
tmux 9617 uzer.buzer 7u unix 0xffff881ff0c73480 0t0 995795763 /tmp/tmux-71358/default
Beachten,wie unterscheidet sich der letzte Socket-Pfad? Zum Glück war das alles, was ich brauchte, und dann habe ich den Attach-Befehl mit einem expliziten Socket ausgeführt:
tmux -S /tmp/tmux-71358/default at
und ich war dabei!!
Antwort4
Für Leute, die später auf diesen Thread stoßen:
Wenn Sie sudo
ein Skript oder etwas anderes ausführen, tmux
wird die Sitzung unter „root“ aufgeführt und nicht unter dem Benutzer, der „sudo“ verwendet hat, da auf „sudo“ folgende Aktionen unter „root“ ausgeführt werden.
Um dies zu beheben, verwenden Sie entweder sudo tmux a
oder tmux
als Root, um die Kontrolle über Ihre Tmux-Sitzung zurückzuerlangen.