Pourquoi le message "échec de connexion au serveur" s'affiche-t-il de la part de tmux lorsque j'essaie de répertorier les sessions?
Voici ce qui m'arrive: je démarre des sessions tmux en utilisant tmux -L name1, tmux -L name2; puis je les détache en utilisant ctrl+B+d. Ensuite, j'essaie d'obtenir une liste des sessions en cours d'exécution sur mon ordinateur. Cependant, lorsque je lance tmux ls, J'obtiens un message d'erreur:
failed to connect to server: Connection refused
Est-ce un bug? Je connais l'écran; Je considère screen -ls comme fonction très utile car je pourrais démarrer une session et la laisser tourner pendant des semaines avant la prochaine fois que je m'y attacherai. Pour cette raison, la possibilité de répertorier les sessions tmux en cours d'exécution est très importante pour moi. Pourquoi tmux ls renvoyer une erreur "connexion refusée" lorsque je sais que tmux est en cours d'exécution?
TL; DR: Essayez d'envoyer SIGUSR1 signal au processus du serveur tmux.
Dans mon cas, après environ 8 jours d'inactivité, je n'ai pas pu rattacher:
$ tmux attach
no sessions
Cependant, un processus grep pour tmux m'a donné cette sortie:
$ ps -aef | fgrep -i tmux
hari 7139 1 1 2016 ? 2-20:32:31 tmux
hari 25943 25113 0 22:00 pts/0 00:00:00 fgrep --color=auto -i tmux
Comme suggéré par @ 7heo.tk, cela indique que le serveur tmux est toujours en cours d'exécution, mais tmux ls donnait failed to connect to server: Connection refused Erreur. J'ai vérifié que le répertoire tmp qui appartenait à la session tmux existait et lsof -p 7139 (le pid du serveur tmux) a montré que le fichier socket est ouvert:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 7139 hari 5u unix 0x0000000000000000 0t0 1712879255 /tmp/tmux-50440/default
J'ai également essayé de spécifier explicitement le -S /tmp/tmux-50440/default à tmux mais cela n'a pas aidé. Cependant, j'ai lu dans la page de manuel tmux que l'envoi de SIGUSR1 ferait que tmux recréerait le fichier socket, j'ai donc essayé et j'ai pu trouver immédiatement la session et rattacher:
$ kill -s USR1 7139
$ tmux ls
0: 12 windows (created Mon Apr 18 21:17:55 2016) [198x62]
Cela m'arrive lorsque je n'ai aucune session en cours. Je commence tout juste à utiliser tmux et je ne savais pas que si vous redémarrez votre ordinateur, vous perdez vos sessions, ce qui m'a surpris au début.
Pour ceux d'entre vous qui pensent la même chose: Restaurer la session tmux après le redémarrage . Un résumé de l'article: Utilisez des scripts Shell pour créer vos sessions tmux ou créez une fantaisie Shell history tracker .
Vous obtenez en effet cette erreur s'il n'y a pas de session ouverte. S'il n'y a pas de sessions ouvertes, aucun serveur tmux n'est en cours d'exécution, il ne peut donc pas s'y connecter.
Avec le -L option, vous changez le nom du socket utilisé par le serveur tmux, ce n'est pas un moyen de nommer vos sessions. Vous feriez mieux d'utiliser les commandes suivantes:
tmux new -s name1
tmux new -s name2
Ceux-ci créeront 2 sessions sur un serveur avec le nom de socket par défaut. Vous pouvez maintenant:
$ tmux ls
name1: 1 windows (created Mon Sep 22 10:34:40 2014) [158x40] (attached)
name2: 1 windows (created Mon Sep 22 10:34:43 2014) [158x40] (attached)
Et vous voyez toutes les sessions en cours d'exécution sur le serveur sur le socket par défaut. Vous pouvez rattacher l'un d'eux en utilisant:
tmux attach -d -s name1
-s spécifie le nom de la session-d le détachera de son ancien client (s'il est attaché)
Vous pouvez également basculer entre les sessions dans tmux avec le choose-tree commande qui par défaut est affectée à la frappe C-s (clé de préfixe + s). C'est ce que je fais d'habitude.
Cela m'est arrivé lorsque le bureau Ubuntu s'est écrasé et que mes fenêtres de terminal gnome se sont fermées. Je pouvais toujours voir que le processus tmux était en cours d'exécution (ps aux | grep tmux) mais pour une raison quelconque, les commandes tmux ne fonctionneraient pas pour répertorier les sessions existantes. Apparemment, il ne trouvait pas le socket Unix existant du processus tmux toujours en cours. Le correctif dans ce scénario consiste à localiser le socket Unix existant et à le spécifier pour tmux à l'aide du -S drapeau; Voici comment:
Vous pouvez trouver le PID de votre processus tmux en cours d'exécution avec ceci:
ps -p $(pidof tmux)
Maintenant, prenez votre PID (dans mon cas, 6876) et exécutez-le pour répertorier tous les sockets Unix ouverts:
Sudo lsof -Uap 6876
J'espère que vous voyez une sortie comme celle-ci:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 6876 abe 3u unix 0x0000000000000000 0t0 408477 socket
tmux 6876 abe 4u unix 0x0000000000000000 0t0 408478 socket
tmux 6876 abe 6u unix 0x0000000000000000 0t0 408479 /tmp/tmux-1000/default
Vous pouvez maintenant spécifier ce socket Unix existant dans votre commande tmux (en utilisant le -S flag), et vous devriez pouvoir lister les sessions et les attacher correctement:
tmux -S /tmp/tmux-1000/default list-sessions
tmux -S /tmp/tmux-1000/default attach -t 0
Vous pouvez avoir une erreur dans votre .tmux.conf. J'ai eu ce problème jusqu'à ce que je retire cette ligne de mon .tmux.conf:
set-window-option -g xterm-keys on
Vous pouvez également essayer tmux -v puis regardez les journaux qu'il imprime.
Une solution simple consiste à supprimer les fichiers tmp laissés par le serveur tmux, par exemple, en faisant $ rm -rf /tmp/tmux-xxx/.
La façon dont TMUX(1) fonctionne est d'avoir un processus client (tmux) connecté à un processus serveur (tmux aussi, mais non attaché à un TTY), comme indiqué dans le sortie ps suivante:
PID TTY STAT TIME COMMAND
19229 pts/1 S+ 0:00 tmux
19231 ? Ss 0:00 tmux
Cela montre que le client démarre réellement avant le serveur (on pourrait supposer qu'il le bifurque).
Après détacher/rattacher, la même commande ps génère:
PID TTY STAT TIME COMMAND
19231 ? Ss 0:00 tmux
19290 pts/1 S+ 0:00 tmux attach
Cela montre le client tmux comme tmux attach, étant ainsi un peu plus facile à comprendre.
Maintenant, si nous regardons la sortie de pstree dans les deux cas ci-dessus, nous obtenons dans les deux cas (en ignorant le changement de pid pour tmux attach):
pstree -p
init(1)─┬─acpid(1824)
├─cron(1859)
⋮
├─sh(14146)───tmux(19229)
└─tmux(19231)───sh(19233)───pstree(19234)
Indiquant clairement que les commandes tapées (pstree dans ce cas) dans le processus client (PID 19229) exécuté par le serveur (PID 19231), leur permettant ainsi de continuer sans SOUPIR en cas de perte du terminal client (sur ssh par exemple).
Maintenant, à la question posée par OP: que se passe-t-il dans le cas où tmux renvoie failed to connect to server: Connection refused est que le processus serveur (pid 19231 dans notre cas) est inaccessible, quelle qu'en soit la raison (cela peut être dû au fait que le processus serveur est mort; mais aussi parce que l'utilisateur exécutant le client tmux n'a pas les autorisations pour accéder à la prise tmux, etc.)
La solution dans ce cas est de grep pour les processus tmux (via ps par exemple), et priez pour que vous n'obteniez pas cette erreur car le serveur est mort (donc vous pouvez y attacher en utilisant lsof pour obtenir les sockets qu'il écoute). Sinon, il n'y a aucun moyen de attacher au serveur, car il est aussi mort qu'après un redémarrage.
TL; DR:
Cette erreur peut être donnée pour plusieurs raisons, allant du bogue à l'échec critique (le programme est mort). En bref, utilisez les outils UNIX à votre disposition pour déterminer quel socket tmux utilise, s'il est toujours en cours d'exécution (il devrait y avoir au moins deux processus si vous avez le client tmux en cours d'exécution - cela se produit après avoir appelé tmux ou tmux attach du Shell) et donc si vous avez perdu votre session ou non.
Remarque: comme d'autres réponses l'ont souligné, si la raison de cette erreur à afficher est une erreur de socket, vous pouvez utiliser le -L drapeau pour indiquer à tmux d'utiliser une socket spécifique.
J'utilisais un autre programme à l'intérieur de tmux (rattacher à l'espace de noms utilisateur) et j'obtenais cette erreur lorsque j'ai changé d'ordinateurs car l'espace de noms rattacher à l'utilisateur n'a pas été installé. Le correctif consistait simplement à exécuter brew install reattach-to-user-namespace.
Cela peut se produire si vous ou tout autre processus de nettoyage supprimez des fichiers dans /tmp/*. Toutes vos données de sessions sont perdues si vous ne pouvez pas récupérer ces fichiers. Tuer toutes les instances de tmux et le redémarrer est malheureusement le seul choix qui reste.