Перенаправьте stderr из уже запускающего скрипта

Только для добавления этого к соединению мы закончили тем, что использовали HTMLUnit вместо вышеупомянутого.

14
15.08.2012, 01:43
2 ответа

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

 perl -e 'do { print "x\n"; sleep(1) } while(1)'

и это работает, но к сожалению не с подобным сценарием удара.


В первую очередь, необходимо выяснить PID того процесса, чей производит Вас, хотят получить. Затем запустите gdb в другом терминале и выполняют следующие gdb-команды

attach PID
call close(2)
call open("/abs/olu/te/path/filename", 65, 384)
detach PID

после этого целые данные, которые записаны в stderr перенаправляется к /abs/olu/te/path/filename, с тех пор

  • attach PID присоединяет процесс к gdb и останавливает его
  • call close(2) завершения stderr filedescriptor процесса (для stdout filedescriptor 1)
  • call open(...) открывает новый файл и берет самое низкое неиспользованное целое число для недавно созданного filedescriptor и
  • detach PID продолжает процесс

По крайней мере, на моей машине. Первыми двумя строками является совместимый POSIX, но не третий.

Второе и третий аргумент open в третьей строке документируются в man 2 open. В моем случае 65 средств это open должен создать файл и открыть файл, только для записи т.е. O_WRONLY | O_CREAT (определенный в fcntl.h). Третий аргумент говорит открытый создавать файл с чтением и разрешением записи для пользователя т.е. S_IWUSR | S_IRUSR (определенный в sys/stat.h). Таким образом, возможно, необходимо узнать соответствующие значения на машине собой.

12
27.01.2020, 19:51
  • 1
    , Это работало так невероятно хорошо... слава!! –  Robottinosino 19.08.2012, 23:24

Это - сырой ответ, и я надеюсь, что кто-то еще добивается большего успеха, но если никакая другая поверхность идей, присоединение gdb и не вынуждает процесс сделать несколько syscalls:

(gdb) attach 12345 # target PID
(gdb) p close(2)
(gdb) p open("errfile", O_WRONLY)
(gdb) c
8
27.01.2020, 19:51
  • 1
    Острота. Я не был осведомленным gdb, мог сделать это. Там какой-либо путь состоит в том, чтобы вызвать его к определенному числу дескриптора файла? Как говорят, не использован ли FD 1, и open() FD 1 захватов? Или необходимо ли просто звонить dup() несколько раз? –  Patrick 15.08.2012, 02:53
  • 2
    делает p open("errfile", O_WRONLY) действительно работайте над своей машиной? –  user1146332 15.08.2012, 03:07
  • 3
    Вы могли всунуть a p dup2(xxx, 2) и затем p close(xxx) где xxx возвращаемое значение open. Это - хитрый материал, лучше не используют эти команды на продолжительном процессе, пока Вы не уверены, что нет никакого другого выбора. –  Alan Curry 15.08.2012, 03:08
  • 4
    @user1146332, который это сделало, когда я попробовал его, потому что я использовал /dev/null как мой errfile таким образом, мне не было нужно O_CREAT. И O_WRONLY будучи макросом, расширяется ли это или не зависит от того, остановил ли gdb процесс в строке, где отладочная информация доступна и макрос определяется. Введение кода в процесс с gdb опасно, и никто просто не должен копировать эти команды, не понимая их. –  Alan Curry 15.08.2012, 03:18
  • 5
    @AlanCurry я не думаю, что gdb разворачивает макросы, если общая отладочная информация доступна. Необходимо скомпилировать источники со специальными флагами (см. здесь). Помимо этого является очень редким, что произвольный исполняемый файл в Вашей системе имеет включенную отладочную информацию (позвольте anlone, информация расширяется с помощью макро-информации). Но я соглашаюсь с Вами, что инжекция кода обычно не желательна, но могли бы быть случаи, где Вы извлекаете выгоду. –  user1146332 15.08.2012, 11:45

Теги

Похожие вопросы