Если кто-то действительно хочет эти данные, я бы предложил подключить отладчик 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для всех ваших усилий командной строки!
fileobject.c), чем 2.7 . Кто-то должен покопаться вioмодуле.Там нет решения вашей непосредственной проблемы. Если ваш скрипт уже запущен, вы не можете изменить режим буферизации по факту. Это все буферы в памяти, и все это устанавливается при запуске скрипта, при открытии файловых дескрипторов, создании каналов и т. Д.
В общем, если и только если некоторая или вся рассматриваемая буферизация выполняется на уровне ввода-вывода на выходе, вы можете выполнить
syncкоманду; но это обычно маловероятно в таком случае.В будущем вы можете использовать
-uопцию Python * для запуска скрипта. В общем, многие команды имеют специфичные для команды опции для отключения буферизации stdin / stdout, и вы также можете добиться общего успеха сunbufferкомандой изexpectпакета.« Ctrl+» CПриведет к сбросу буферов системного уровня при прерывании программы, если только буферизация не выполняется самим Python и в нем не реализована логика сброса собственных буферов с « Ctrl+» C. Приостановка, сбой или убийство не будут такими добрыми.
* Принудительно отключить буферизацию stdin, stdout и stderr.
источник
Python 2.7.7 Документация, раздел «Настройка и использование Python», подраздел 1. Командная строка и среда , описывает этот аргумент Python:
А также эта переменная среды:
источник
sys.stdout.flush(), но ваш-uвариант кажется еще проще), но просто забыл сделать это при вызове моего кода. После того, как мой код был запущен более недели, я надеялся, что есть способ получить результат без необходимости повторного запуска кода в течение еще одной недели.Похоже, я был слишком осторожен с потерей буферизованного вывода после запуска Ctrl-C; в соответствии с этим постом я должен ожидать, что буфер будет очищен, если моя программа имеет нормальный выход, что было бы, если бы я нажал Ctrl-C. С другой стороны, я бы потерял буферизованный вывод, если бы убил скрипт с помощью SIGKILL или подобного.
источник
Я думаю, что другое возможное решение может заключаться в том, чтобы принудительно завершить процесс с выгруженным ядром, а затем посмертно анализировать содержимое памяти.
источник