Existe-t-il un moyen d’empêcher le gel de tmux lorsque de nombreux textes sont envoyés au terminal?

Dans une session tmux à l'intérieur de xterm lorsqu'un programme génère beaucoup de sorties (comme une cat very_long_filesession entière figée pendant un moment. Même si j'appuie sur Ctrl-C, rien n'est interrompu. Probablement parce que tmux est gelé et ne transmet pas le Ctrl-C à le programme générant la sortie, existe-t-il un moyen de l’empêcher?

La bonne solution consiste à examiner les options c0- * pour que tmux tente de limiter la sortie. La raison pour laquelle ce problème existe est due au fait que les données sont envoyées au terminal plus rapidement qu'il ne peut les afficher. La limitation du débit est donc le seul moyen.

J'ai toujours ce problème dans tmux 1.6-2 sur Ubuntu 12.10. Une solution de contournement que j'ai trouvée consiste à détacher de la session (préfixe + d) puis à se rattacher ( tmux attachbon candidat pour un alias de shell rapide). Il semble que tmux soit réellement réactif sous le capot --- vous pouvez confirmer que votre processus est réellement tué immédiatement avec ctrl-c --- c'est simplement le dessin qui bloque. Détacher fonctionne immédiatement et lorsque vous vous attachez, le dessin sera passé à la fin.

Autant que je sache, il n'y a aucun moyen de l'éviter dans les versions actuelles, mais certains travaux sont en cours. Vous pouvez trouver des correctifs sur la liste de diffusion de tmux http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689 .

Le "contrôle de flux" est un bon mot clé pour effectuer une recherche sur le Web.

Malheureusement, les options c0- * pour la limitation de débit ont été supprimées à partir de la version 2.1 de tmux ( changelog ). Autant que je sache, le seul moyen de personnaliser la limitation de débit est de mettre à jour les variables qui l’influencent dans le code source (tmux.h):

" READ_SIZE est la taille maximale des données d’une pile (l’événement en filigrane élevé). READ_BACKOFF est la quantité de données en attente de sortie vers un tty avant que les lectures de pty ne soient sauvegardées. READ_TIME est le temps de sauvegarde avant prochaine lecture (en microsecondes) si un terminal est supérieur à READ_BACKOFF. "

Où vous trouverez les valeurs par défaut: (à partir de tmux v2.2):

#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100

La réponse https://superuser.com/a/589896/311481 fonctionne bien. J'utilise les valeurs suivantes:

setw -g c0-change-trigger 10
setw -g c0-change-interval 250

Autre astuce: si vous utilisez ssh dans tmux, utilisez plutôt mosh: http://mosh.mit.edu/ Il se comporte mieux en ce qui concerne l'affichage des résultats des programmes. Il essaie d’afficher le dernier état de l’écran en laissant tomber les intermédiaires, le cas échéant. Donc, tmux ne gèlera jamais si beaucoup de sorties sont générées dans ses volets avec des sessions mosh à l'intérieur.

Contrairement à SSH, le protocole basé sur UDP de mosh gère correctement la perte de paquets et définit le taux de trame en fonction des conditions du réseau. Mosh ne remplit pas les tampons réseau, donc Control-C fonctionne toujours pour arrêter un processus emballé.

Étant donné que le protocole SSP [protocole de synchronisation d'état utilisé par mosh] fonctionne au niveau de la couche d'objet et peut contrôler le taux de synchronisation (en d'autres termes, le taux de trame), il n'est pas nécessaire d'envoyer chaque octet reçu de l'application. Cela signifie que Mosh peut réguler les trames afin de ne pas remplir les mémoires tampon du réseau, en conservant la réactivité de la connexion et en s'assurant que Control-C fonctionne toujours rapidement. Les protocoles qui doivent envoyer chaque octet ne peuvent pas faire cela.

Essayez un autre émulateur de terminal. Sur RedHat 6.5, la konsole (KDE) n’a pas le problème de gel (tmux 2.3 et master); Cependant, xterm et gnome-terminal sont tous les deux gelés.