Принудительная очистка буфера вывода в работающей программе

У меня есть долго работающий скрипт Python, который периодически выводит данные в стандартный вывод, который я вызывал с чем-то вроде:

python script.py > output.txt

Этот скрипт был запущен некоторое время, и я хочу остановить его с помощью Ctrl+, Cно не потерять его вывод. К сожалению, когда я реализовал сценарий, я забыл очищать буфер после каждой строки вывода чем-то вроде sys.stdout.flush()( ранее предложенное решение для принудительной очистки вывода), поэтому вызов Ctrl+ Cпрямо сейчас заставит меня потерять весь вывод.

Если вам интересно, есть ли какой-нибудь способ взаимодействия с работающим скриптом Python (или, в более общем случае, с запущенным процессом), чтобы заставить его очистить выходной буфер. Я не спрашиваю, как отредактировать и повторно запустить скрипт, чтобы заставить его корректно сбрасываться - этот вопрос конкретно о взаимодействии с запущенным процессом (и, в моем случае, не о потере вывода из моего текущего выполнения кода).

Если кто-то действительно хочет эти данные, я бы предложил подключить отладчик gdb к интерпретатору python, на мгновение остановить задачу, вызвать fsync(1)( stdout ), отсоединиться от нее (возобновить процесс) и перейти к просмотру выходного файла.

Посмотрите, /proc/$(pidof python)/fdчтобы увидеть действительные файловые дескрипторы. $(pidof x)возвращает PID процесса с именем ' x'.

# your python script is running merrily over there.... with some PID you've determined.
#
# load gdb
gdb
#
# attach to python interpreter (use the number returned by $(pidof python))
attach 1234
#
# force a sync within the program's world (1 = stdout, which is redirected in your example)
call fsync(1)
#
# the call SHOULD have returned 0x0, sync successful.   If you get 0xffffffff (-1), perhaps that wasn't stdout.  0=stdin, 1=stdout, 2=stderr
#
# remove our claws from poor python
detach
#
# we're done!
quit

Я использовал этот метод, чтобы изменить рабочий каталог, настроить параметры на лету ... многие вещи. Увы, вы можете вызывать только те функции, которые определены в работающей программе, но fsyncработает хорошо.

(Команда GDB ' info functions' выведет список всех доступных функций. Будьте осторожны. Вы работаете с LIVE в процессе.)

Также есть команда peekfd(находится в psmiscпакете на Debian Jessie и других), которая позволит вам увидеть, что скрывается в буферах процесса. Опять же, /proc/$(pidof python)/fdпокажет вам действительные файловые дескрипторы, чтобы предоставить в качестве аргументов peekfd.

Если вы не помните -uPython, вы всегда можете добавить к команде префикс stdbuf(in coreutils, уже установленный), чтобы установить для stdin / stdout / stderr значение unbuffered, буферизацию строки или буферизацию блока по желанию:

stdbuf -i 0 -o 0 -e 0 python myscript.py > unbuffered.output

Конечно, man pagesтвои друзья, эй! возможно, псевдоним может быть полезен и здесь.

alias python='python -u'

Теперь ваш Python всегда использует -uдля всех ваших усилий командной строки!

Сначала убедитесь, что у вас есть символы отладки для Python (или хотя бы glibc). На Fedora ¹ вы можете установить их с помощью:

dnf debuginfo-install python

Затем присоедините gdb к запущенному сценарию и выполните следующие команды:

[user@host ~]$ pidof python2
9219
[user@host ~]$ gdb python2 9219
GNU gdb (GDB) Fedora 7.7.1-13.fc20
...
0x00007fa934278780 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
81  T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) call fflush(stdout)
$1 = 0
(gdb) call setvbuf(stdout, 0, 2, 0)
$2 = 0
(gdb) quit
A debugging session is active.

    Inferior 1 [process 9219] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/bin/python2, process 9219

Это очистит стандартный вывод, а также отключит буферизацию. Значение 2от setvbufвызова является значением в _IONBFмоей системе. Вам нужно будет выяснить, что у вас ( grep _IONBF /usr/include/stdio.hнужно сделать свое дело).

Исходя из того, что я видел в реализации PyFile_SetBufSizeи PyFile_WriteStringв CPython 2.7, он должен работать довольно хорошо, но я не могу дать никаких гарантий.

^{1 Fedora включает в себя специальный тип RPM, называемый debuginfo rpms . Эти автоматически созданные RPM содержат информацию об отладке из программных файлов, но перемещены во внешний файл.}

Там нет решения вашей непосредственной проблемы. Если ваш скрипт уже запущен, вы не можете изменить режим буферизации по факту. Это все буферы в памяти, и все это устанавливается при запуске скрипта, при открытии файловых дескрипторов, создании каналов и т. Д.

В общем, если и только если некоторая или вся рассматриваемая буферизация выполняется на уровне ввода-вывода на выходе, вы можете выполнить syncкоманду; но это обычно маловероятно в таком случае.

В будущем вы можете использовать -uопцию Python ^* для запуска скрипта. В общем, многие команды имеют специфичные для команды опции для отключения буферизации stdin / stdout, и вы также можете добиться общего успеха с unbufferкомандой из expectпакета.

« Ctrl+» CПриведет к сбросу буферов системного уровня при прерывании программы, если только буферизация не выполняется самим Python и в нем не реализована логика сброса собственных буферов с « Ctrl+» C. Приостановка, сбой или убийство не будут такими добрыми.

_{^* Принудительно отключить буферизацию stdin, stdout и stderr.}

Python 2.7.7 Документация, раздел «Настройка и использование Python», подраздел 1. Командная строка и среда , описывает этот аргумент Python:

-u

Заставьте stdin, stdout и stderr быть полностью небуферизованными. В системах, где это важно, также установите stdin, stdout и stderr в двоичном режиме.

Обратите внимание, что в file.readlines () и File Objects (для строки в sys.stdin) есть внутренняя буферизация, на которую не влияет эта опция. Чтобы обойти это, вы захотите использовать file.readline () внутри цикла while 1 :.

А также эта переменная среды:

PYTHONUNBUFFERED

Если для этого параметра задана непустая строка, это эквивалентно указанию опции -u.

Похоже, я был слишком осторожен с потерей буферизованного вывода после запуска Ctrl-C; в соответствии с этим постом я должен ожидать, что буфер будет очищен, если моя программа имеет нормальный выход, что было бы, если бы я нажал Ctrl-C. С другой стороны, я бы потерял буферизованный вывод, если бы убил скрипт с помощью SIGKILL или подобного.

Я думаю, что другое возможное решение может заключаться в том, чтобы принудительно завершить процесс с выгруженным ядром, а затем посмертно анализировать содержимое памяти.