Wyłącz buforowanie w rurze

Mam skrypt, który wywołuje dwa polecenia:

long_running_command | print_progress

Te long_running_commandodciski postęp, ale jestem zadowolony z niego. Używam, print_progressaby uczynić to ładniejszym (mianowicie, drukuję postęp w jednym wierszu).

Problem: Podłączenie rury do standardowego wyjścia również aktywuje bufor 4K, do ładnego programu do drukowania nic nie dostaje ... nic ... nic ... dużo ... :)

Jak mogę wyłączyć bufor 4K dla long_running_command(nie, nie mam źródła)?

Możesz użyć unbufferpolecenia (które jest częścią expectpakietu), np

unbuffer long_running_command | print_progress

unbufferłączy się long_running_commandz pseudoterminalem (pty), co sprawia, że ​​system traktuje go jako proces interaktywny, dlatego nie wykorzystuje buforowania 4-kiB w potoku, który jest prawdopodobną przyczyną opóźnienia.

W przypadku dłuższych potoków może być konieczne cofnięcie buforowania każdego polecenia (z wyjątkiem ostatniego), np

unbuffer x | unbuffer -p y | z

Innym sposobem na skórowanie tego kota jest użycie stdbufprogramu, który jest częścią GNU Coreutils (FreeBSD ma również swój własny).

stdbuf -i0 -o0 -e0 command

To całkowicie wyłącza buforowanie danych wejściowych, wyjściowych i błędów. W przypadku niektórych aplikacji buforowanie linii może być bardziej odpowiednie ze względu na wydajność:

stdbuf -oL -eL command

_{Pamiętaj, że działa tylko w przypadku stdiobuforowania ( printf(), fputs()...) w przypadku dynamicznie połączonych aplikacji i tylko wtedy, gdy aplikacja sama nie dostosuje buforowania swoich standardowych strumieni, chociaż powinno to obejmować większość aplikacji.}

Jeszcze innym sposobem włączenia trybu wyjścia buforowania linii dla long_running_commandjest użycie scriptpolecenia, które uruchamia twój 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

Na grep, sedi awkmożna wymusić wyjście być linia buforowane. Możesz użyć:

grep --line-buffered

Wymusza buforowanie wyjścia. Domyślnie wyjście jest buforowane liniowo, gdy standardowe wyjście jest terminalem, a blok buforowany w inny sposób.

sed -u

Spraw, aby linia wyjściowa była buforowana.

Zobacz tę stronę, aby uzyskać więcej informacji: http://www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html

Jeśli jest problem z libc modyfikującym buforowanie / opróżnianie, gdy dane wyjściowe nie trafiają do terminala, powinieneś spróbować socat . Możesz utworzyć dwukierunkowy strumień między prawie każdym rodzajem mechanizmu we / wy. Jednym z nich jest rozwidlony program mówiący do pseudo tty.

 socat EXEC:long_running_command,pty,ctty STDIO 

Co to robi

• utwórz pseudo tty
• fork long_running_command z niewolniczą stroną pty jako stdin / stdout
• ustanowić dwukierunkowy strumień między stroną główną pty a drugim adresem (tutaj jest STDIO)

Jeśli daje to taką samą wydajność jak long_running_command, możesz kontynuować z potokiem.

Edycja: Wow Nie widziałem odpowiedzi niebuforowanej! Cóż, socat i tak jest świetnym narzędziem, więc mogę zostawić tę odpowiedź

Możesz użyć

long_running_command 1>&2 |& print_progress

Problem polega na tym, że libc będzie buforował linię, gdy standardowe wyjście do ekranu, i pełny bufor, gdy standardowe wyjście do pliku. Ale brak bufora dla stderr.

Nie sądzę, że to jest problem z buforem potoku, wszystko dotyczy polityki buforów libc.

Kiedyś tak było i prawdopodobnie nadal tak jest, że kiedy standardowe wyjście jest zapisywane na terminalu, to jest ono domyślnie buforowane w linii - kiedy zapisywany jest nowy wiersz, wiersz jest zapisywany na terminalu. Gdy standardowe wyjście jest wysyłane do potoku, jest w pełni buforowane - więc dane są wysyłane do następnego procesu w potoku, gdy standardowy bufor We / Wy jest wypełniony.

To jest źródłem kłopotów. Nie jestem pewien, czy można wiele zrobić, aby to naprawić bez modyfikacji programu zapisującego w potoku. Możesz użyć setvbuf()funkcji z _IOLBFflagą, aby bezwarunkowo przejść stdoutdo trybu buforowania linii. Ale nie widzę łatwego sposobu na wymuszenie tego w programie. Lub program może zrobić fflush()w odpowiednich punktach (po każdym wierszu wyniku), ale stosuje się ten sam komentarz.

Przypuszczam, że jeśli zastąpisz potok pseudo-terminalem, wówczas standardowa biblioteka I / O uznałaby, że wyjście jest terminalem (ponieważ jest to rodzaj terminala) i automatycznie buforowałaby linię. Jest to jednak złożony sposób radzenia sobie z rzeczami.

Wiem, że to stare pytanie i już miałem wiele odpowiedzi, ale jeśli chcesz uniknąć problemu z buforem, po prostu spróbuj czegoś takiego:

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

Spowoduje to wyświetlenie dzienników w czasie rzeczywistym, a także zapisanie ich w logs.txtpliku, a bufor nie będzie już wpływał na tail -fpolecenie.

Nie sądzę, że problem tkwi w fajce. Wygląda na to, że twój długotrwały proces nie czyści wystarczająco własnego bufora. Zmiana rozmiaru bufora potoku byłaby włamaniem do obejścia go, ale nie sądzę, że jest to możliwe bez przebudowania jądra - coś, czego nie chciałbyś robić jako włamania, ponieważ prawdopodobnie wywrze negatywny wpływ na wiele innych procesów.

Zgodnie z tym postem tutaj możesz spróbować zmniejszyć ulimit rury do jednego pojedynczego 512-bajtowego bloku. Z pewnością nie wyłączy buforowania, ale cóż, 512 bajtów to znacznie mniej niż 4K: 3

Podobnie jak odpowiedź Czada , możesz napisać taki skrypt:

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

Następnie użyj tego scripteepolecenia jako zamiennika dla tee.

my-long-running-command | scriptee

Niestety, nie wydaje mi się, aby taka wersja działała idealnie w systemie Linux, więc wydaje się ograniczona do uniksów w stylu BSD.

W systemie Linux jest to blisko, ale nie wyświetla się monit po jego zakończeniu (dopóki nie naciśniesz enter itp.) ...

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

Znalazłem to sprytne rozwiązanie: (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable

To załatwia sprawę. catodczyta dodatkowe dane wejściowe (do EOF) i przekaże je do potoku po echoumieszczeniu swoich argumentów w strumieniu wejściowym shell_executable.

Zgodnie z tym rozmiar bufora potoku wydaje się być ustawiony w jądrze i wymaga zmiany kompilacji jądra.