Comment puis-je rattacher à une session mosh détachée?

157

Comment puis-je me rattacher à une session mosh détachée ou me débarrasser

Mosh: You have a detached Mosh session on this server (mosh [XXXX]).

c'est-à-dire quel est l'équivalent mosh de

screen -D -R

ou éventuellement

screen -wipe

De plus, où trouver cette réponse dans la documentation?

John Baber-Lucero
la source

Réponses:

197

Pour des raisons de sécurité, vous ne pouvez pas rattacher, voir https://github.com/keithw/mosh/issues/394

Pour tuer la session détachée, utilisez le numéro PID affiché dans ce message (c'est la partie 'XXXX'.) Par exemple, si vous voyez -

Mosh: You have a detached Mosh session on this server (mosh [12345]).

Et peut exécuter cette commande:

kill 12345

De plus, pour fermer toutes les connexions mosh, vous pouvez:

kill `pidof mosh-server`

Notez que si vous êtes actuellement connecté via mosh, cette dernière commande vous déconnectera également.

varta
la source
34
@artfulrobot Parce qu'il y a une chance que la session détachée appartienne à un mosh-client qui est encore vivant quelque part. Les sessions Mosh sont itinérantes et peuvent survivre à travers un cycle de suspension / reprise (par exemple, «Hibernation»). Le problème que mosh ne résout pas (et ne peut pas facilement) est de détecter que la machine cliente a redémarré sans fermer correctement la session mosh.
binki
7
Y a-t-il une raison de ne pas à la killall mosh-serverplace? D'autant plus que pidof et killall sont vraiment la même chose de toute façon.
Jordanie
6
@Jordan: Sur certains systèmes (Solaris, par exemple), killallfait exactement ce qu'il dit.
Suspendu jusqu'à nouvel ordre.
4
Si vous êtes connecté via mosh et que vous exécutez, killall mosh-servervous serez déconnecté.
0xcaff
1
@ 0xcaff si vous vous connectez via mosh et exécutez, kill `pidof mosh-server`vous serez détaché de la même manière
David
26

À ma grande surprise, j'ai utilisé CRIU ( https://criu.org ) pour vérifier et redémarrer un client mosh et cela a fonctionné.

Choquant.

Trouvez le PID de votre client mosh:

$ ps -ef | grep mosh

Ensuite, installez CRIU selon leurs instructions.

Ensuite, vérifiez-le comme ceci:

point de contrôle $ mkdir

$ sudo ./criu dump -D point de contrôle -t PID --shell-job

Ensuite, restaurez-le:

$ sudo ./criu restore -D point de contrôle --shell-job

Et ça y est. Votre client mosh est de retour.

Une chose à noter, cependant, est que si votre ordinateur portable redémarre (ce qui est le but de ce contre quoi nous essayons de nous protéger), mosh utilise une monotonichorloge pour suivre l'heure côté client, ce qui ne fonctionne pas entre les redémarrages. Cela ne fonctionnera PAS, cependant, si votre ordinateur portable tombe tout simplement en panne, cela ne fonctionnera pas car les numéros de séquence mosh ne seront pas synchronisés avec la version qui a été vérifiée (le binaire reprendra, mais la communication s'arrêtera).

Pour résoudre ce problème, vous devez dire à mosh d'arrêter de le faire et télécharger le code source de mosh. Ensuite, éditez ce fichier:

cd mosh

vim configure.ac

Ensuite, recherchez GETTIMEet commentez cette ligne.

Alors fais:

autoreconf # ou ./autogen.sh si vous venez de le cloner pour la première fois

./configure

faire

faire installer

Après cela, vos sessions client mosh contrôlées par CRIU survivront aux redémarrages.

(De toute évidence, vous auriez besoin d'écrire quelque chose pour effectuer les points de contrôle assez régulièrement pour être utile. Mais c'est un exercice pour le lecteur).

Michael Galaxy
la source
1
Veillez à taper «CTRL-L» pour actualiser la sortie de l'écran après la restauration.
Michael Galaxy
6
Par pure curiosité, y a-t-il un avantage pratique à restaurer la session client mosh qui me manque? Je lance tmux sur mosh et je peux simplement relancer mosh sur le client et reconnecter le tmux ... y a-t-il un avantage à faire cela autre que son cool (ce que c'est vraiment!)?
eskhool
1
La réponse longue: github.com/mobile-shell/mosh/issues/394 La réponse courte est oui: il ne faut pas avoir besoin d'une session tmux si le démon mosh-server est déjà en cours d'exécution sur le serveur cible. Cela laisse non seulement des démons mosh suspendus, mais c'est une autre série de frappes que nous ne devrions pas avoir à taper en premier lieu.
Michael Galaxy
1
Mosh est un substitut (dans certains cas) à SSH, pas à screen. quoth keithw (auteur mosh) sur github
törzsmókus
19

Je me rends compte qu'il s'agit d'un ancien article, mais il existe une solution très simple à cela, comme suggéré par Keith Winstein, auteur de mosh, ici: https://github.com/mobile-shell/mosh/issues/394

"Eh bien, tout d'abord, si vous voulez pouvoir vous connecter à une session à partir de plusieurs clients (ou après la mort du client), vous devriez utiliser screen ou tmux. Mosh est un substitut (dans certains cas) pour SSH, pas pour screen. De nombreux utilisateurs de Mosh l'utilisent avec un écran et l'apprécient ainsi. "

Scénario: je suis connecté à un serveur distant via mosh. J'ai ensuite exécuté screen et j'ai un processus en cours d'exécution dans la session d'écran, htop, par exemple. Je perds la connexion (la batterie de l'ordinateur portable meurt, perd la connexion réseau, etc.). Je me connecte à nouveau via mosh et reçois ce message sur le serveur,

Mosh: Vous avez une session Mosh détachée sur ce serveur (mosh [XXXX]).

Tout ce que j'ai à faire est de tuer la session précédente

tuer XXXX

et rattachez-le à la session d'écran, qui existe toujours .

écran -r

Maintenant, htop (ou tout autre processus en cours d'exécution) est de retour tel qu'il était sans interruption, ce qui est particulièrement utile pour exécuter des mises à niveau ou d'autres processus qui laisseraient le serveur dans un état désordonné et inconnu s'il était soudainement interrompu. Je suppose que vous pouvez faire la même chose avec tmux, même si je ne l'ai pas essayé. Je crois que c'est ce que suggéraient Annihilannic et eskhool.

007
la source
2
C'est une excellente réponse. Merci, et oui j'ai confirmé que ça marche de la même façon avec tmux.
laughing_man
10

En plus de la réponse de Varta, j'utilise la commande suivante pour fermer toutes les connexions mosh sauf celle actuelle:

pgrep mosh-server | grep -v $(ps -o ppid --no-headers $$) | xargs kill

Alexander Burmak
la source
Dans le cas où il n'y aurait pas d'ancienne session mosh, xkill lancera une erreur. Meilleure utilisationpgrep mosh-server | grep -v $(ps -o ppid --no-headers $$) && xargs kill || echo "no active sessions to kill"
rubo77
4

Comme @varta l'a souligné, les propriétaires de mosh sont très opposés au rattachement de différents clients pour des raisons de sécurité. Donc, si votre client est parti (par exemple, vous avez redémarré votre ordinateur portable), votre seule option est de tuer les sessions.

Pour tuer uniquement les sessions détachées, vous pouvez utiliser la ligne suivante (que j'ai comme alias dans my .bashrc).

who | grep -v 'via mosh' | grep -oP '(?<=mosh \[)(\d+)(?=\])' | xargs kill

Cette commande dépend du fait que wholes utilisateurs connectés incluent les sessions mosh, seules les sessions mosh attachées ont "via mosh", et que les sessions mosh ont leur pid entre crochets. Il trouve donc les pids pour les sessions mosh détachées uniquement et les transmet à tuer en utilisant xargs.

Voici un exemple de whorésultat pour référence:

$ who
theuser    pts/32       2018-01-03 08:39 (17X.XX.248.9 via mosh [193891])
theuser    pts/17       2018-01-03 08:31 (17X.XX.248.9 via mosh [187483])
theuser    pts/21       2018-01-02 18:52 (mosh [205286])
theuser    pts/44       2017-12-21 13:58 (:1001.0)

Une alternative consiste à utiliser la variable d'environnement mosh-server MOSH_SERVER_SIGNAL_TMOUT. Vous pouvez le mettre à quelque chose comme 300 dans votre .bashrcsur le côté serveur . Ensuite, si vous faites un, pkill -SIGUSER1 mosh-serveril ne tuera que les serveurs mosh qui n'ont pas été connectés au cours des 300 dernières secondes (les autres ignoreront le SIGUSER1). Plus d'informations dans la page de manuel de mosh-server . J'utilise la commande ci-dessus car, une fois aliasée, cela me semble plus simple.

Notez, comme mentionné par @Annihilannic, si vous utilisez tmux / screen dans vos sessions mosh, ces sessions tmux / screen sont toujours là après que vous ayez tué les sessions mosh. Vous pouvez donc toujours vous y attacher (donc vous ne perdez vraiment pas grand chose en tuant les sessions mosh elles-mêmes).

studgeek
la source
3

Les réponses ici affirmant que tuer mosh-serverest la seule option sont largement obsolètes, car nous pouvons utiliser criuet reptyrrécupérer et rattacher des processus arbitraires.

Sans oublier que de nos jours, nous ne pouvons kill -USR1 mosh-servertuer que les sessions détachées de manière propre et sûre, sans recourir à une whosortie non sécurisée ou à des commandes lourdes pour éviter de tuer notre propre session.

À côté de la criuréponse de Michael R. Hines, il y a le légèrement plus «léger» reptyrqui peut être utilisé pour rattacher les processus lancés par mosh-server(c'est-à-dire pas le mosh-serverlui - même). J'utilise généralement

pstree -p <mosh-server PID>

pour lister l'arborescence des processus sous le serveur mosh détaché, puis

reptyr PID

pour rattacher le processus souhaité à mon terminal actuel. Après avoir répété la procédure pour tous les processus qui m'intéressent, je

kill -USR1 <mosh-server PID>

alors que je prends soin de ne tuer que les sessions dont je sais qu'elles sont les miennes (système partagé).

Irfy
la source
Je reçoisUnable to attach to pid 10103: Permission denied
rubo77
-1

Utilisez la commande ps pour obtenir la liste des tâches en cours d'exécution ou utilisez ps -ef | grep mosh

Tuez le mosh PID en utilisant cette commande:

kill <pid>

De plus, pour fermer toutes les connexions mosh, vous pouvez:

Notez que si vous êtes actuellement connecté via mosh, cela vous déconnecte également

kill `pidof mosh-server`
Pankaj Chauhan
la source