Désactiver la mise en mémoire tampon dans le tuyau

J'ai un script qui appelle deux commandes:

long_running_command | print_progress

Les long_running_commandempreintes sont un progrès, mais je ne suis pas satisfait. J'utilise print_progresspour le rendre plus agréable (à savoir, j'imprime la progression en une seule ligne).

Le problème: La connexion d’un tuyau à stdout active également un tampon 4K, le programme d’impression n’obtenant rien… rien… rien… beaucoup … :)

Comment puis-je désactiver le tampon 4K pour le long_running_command(non, je n'ai pas la source)?

Vous pouvez utiliser la unbuffercommande (qui fait partie du expectpaquet), par exemple

unbuffer long_running_command | print_progress

unbufferse connecte à long_running_commandvia un pseudoterminal (pty), ce qui fait que le système le traite comme un processus interactif; par conséquent, n'utilisez pas la mise en mémoire tampon de 4 kio dans le pipeline qui est la cause probable du retard.

Pour les pipelines plus longs, vous devrez peut-être débuffer chaque commande (sauf la dernière), par exemple

unbuffer x | unbuffer -p y | z

Une autre façon de peauner ce chat est d'utiliser le stdbufprogramme, qui fait partie de GNU Coreutils (FreeBSD en possède également un).

stdbuf -i0 -o0 -e0 command

Cela désactive complètement la mise en mémoire tampon pour les entrées, les sorties et les erreurs. Pour certaines applications, la mise en mémoire tampon des lignes peut être plus appropriée pour des raisons de performances:

stdbuf -oL -eL command

_{Notez que cela ne fonctionne que pour la stdiomise en mémoire tampon ( printf(), fputs()...) pour les applications liées dynamiquement, et uniquement si cette application ne règle pas la mise en mémoire tampon de ses flux standard par elle-même, bien que cela devrait couvrir la plupart des applications.}

Une autre façon d'activer le mode de sortie avec mise en mémoire tampon de lignes long_running_commandconsiste à utiliser la scriptcommande qui exécute votre long_running_commandpseudo-terminal (pty).

script -q /dev/null long_running_command | print_progress      # FreeBSD, Mac OS X
script -c "long_running_command" /dev/null | print_progress    # Linux

Pour grep, sedet awkvous pouvez forcer la sortie à la ligne tamponne. Vous pouvez utiliser:

grep --line-buffered

Force la sortie à être mise en mémoire tampon. Par défaut, la sortie est mise en mémoire tampon de ligne lorsque la sortie standard est un terminal et la mise en mémoire tampon de bloc autrement.

sed -u

Rendre la ligne de sortie en mémoire tampon.

Voir cette page pour plus d'informations: http://www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html

S'il y a un problème avec la libc qui modifie sa mise en tampon / vidage lorsque la sortie ne va pas à un terminal, vous devriez essayer socat . Vous pouvez créer un flux bidirectionnel entre presque n'importe quel type de mécanisme d'E / S. Un de ceux-ci est un programme forké qui parle à un pseudo tty.

 socat EXEC:long_running_command,pty,ctty STDIO 

Ce qu'il fait est

• créer un pseudo tty
• fork long_running_command avec le côté esclave du pty comme stdin / stdout
• établir un flux bidirectionnel entre le côté maître du pty et la deuxième adresse (ici c'est STDIO)

Si cela vous donne le même résultat que long_running_command, alors vous pouvez continuer avec un tuyau.

Edit: Wow Vous n'avez pas vu la réponse du tampon! Eh bien, socat est de toute façon un excellent outil, je pourrais donc laisser cette réponse

Vous pouvez utiliser

long_running_command 1>&2 |& print_progress

Le problème est que libc mettra le tampon de ligne lorsque stdout à l'écran et le tampon complet lorsque stdout dans un fichier. Mais pas de tampon pour stderr.

Je ne pense pas que ce soit le problème avec le tampon de pipe, tout repose sur la politique de tampon de libc.

Auparavant, et probablement encore, lorsque la sortie standard est écrite dans un terminal, la ligne est mise en mémoire tampon par défaut. Lorsqu'une nouvelle ligne est écrite, la ligne est écrite dans le terminal. Lorsque la sortie standard est envoyée à un canal, celle-ci est entièrement mise en mémoire tampon. Ainsi, les données ne sont envoyées qu'au processus suivant du pipeline lorsque le tampon d'E / S standard est rempli.

C'est la source du problème. Je ne sais pas si vous pouvez faire grand chose pour résoudre ce problème sans modifier le programme écrit dans le tuyau. Vous pouvez utiliser la setvbuf()fonction avec l' _IOLBFindicateur pour passer inconditionnellement stdouten mode de mise en tampon de ligne. Mais je ne vois pas de moyen facile d'appliquer cela à un programme. Ou bien le programme peut le faire fflush()aux moments appropriés (après chaque ligne de sortie), mais le même commentaire s’applique.

Je suppose que si vous remplaciez le canal par un pseudo-terminal, la bibliothèque d'E / S standard penserait que la sortie est un terminal (car il s'agit d'un type de terminal) et alignera automatiquement le tampon en ligne. C'est une façon complexe de traiter les choses, cependant.

Je sais que c’est une vieille question et que de nombreuses réponses ont déjà été apportées, mais si vous souhaitez éviter le problème de la mémoire tampon, essayez quelque chose du genre:

stdbuf -oL tail -f /var/log/messages | tee -a /home/your_user_here/logs.txt

Cela affichera les journaux en temps réel, les enregistrera également dans le logs.txtfichier et le tampon n’affectera plus la tail -fcommande.

Je ne pense pas que le problème est avec le tuyau. Il semble que votre processus de longue durée ne vide pas suffisamment son propre tampon. Changer la taille de la mémoire tampon du tuyau serait un hack pour le contourner, mais je ne pense pas que ce soit possible sans reconstruire le noyau - ce que vous ne voudriez pas faire comme un hack, car il affectera probablement beaucoup d'autres processus.

Selon ce post , vous pouvez essayer de réduire le tuyau ulimit à un seul bloc de 512 octets. Cela ne désactivera certainement pas la mise en mémoire tampon, mais bon, 512 octets est bien moins que 4K: 3

Dans la même veine que la réponse de chad , vous pouvez écrire un petit script comme celui-ci:

# save as ~/bin/scriptee, or so
script -q /dev/null sh -c 'exec cat > /dev/null'

Ensuite, utilisez cette scripteecommande en remplacement de tee.

my-long-running-command | scriptee

Hélas, je n'arrive pas à faire en sorte qu'une telle version fonctionne parfaitement sous Linux. Cela semble donc être limité aux Unix de type BSD.

Sous Linux, c'est proche, mais vous ne recevez pas votre invite quand elle se termine (jusqu'à ce que vous appuyiez sur entrée, etc.) ...

script -q -c 'cat > /proc/self/fd/1' /dev/null

J'ai trouvé cette solution intelligente: (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable

Cela fait l'affaire. catlira des entrées supplémentaires (jusqu’à EOF) et les transmettra au tube après que le echoa placé ses arguments dans le flux d’entrée de shell_executable.

Selon cela, la taille de la mémoire tampon du tube semble être définie dans le noyau et vous obligerait à recompiler votre noyau pour le modifier.