Перенаправление вывода «на лету» — выглядит невозможным в Linux, почему?

Каждый поток, кроме первого (init ), имеет родительский поток. Вы можете лучше всего увидеть взаимосвязь, используя флаг f для ps, таким образом :"ps faux" (без кавычек ).

2
29.09.2019, 02:16
6 ответов

How was it decided what utility should work with proc - by programmers of that utility?

Нет, разработчиками procfs, виртуальной файловой системы, которая экспортирует информацию о ядре в виде файловой системы, позволяя работать с ней обычным системным вызовам POSIX.

lsи lnпросто делают те же системные вызовы, что и всегда :В Unix все является файлом; в этом весь смысл, и почему вы можете использовать ls -lна /proc/PIDвместо того, чтобы использовать специальный инструмент, такой как lsofилиps.

Вы можете запускать в файле /proc/PID/fd/*все, что хотите, например. если у программы открыт файл конфигурации, вы можете прочитать этот файл с помощью less, отредактировать его с помощью emacsили vimили создать его сжатую копию с помощью gzip < /proc/.../3 > foo.gz

.

Вы можете подумать, что это работает, просто перейдя по символической ссылке. Но на самом деле это не так. lstatв этом файле сообщает о нем как о символической ссылке, а readlink показывает вам цель ссылки. Но эта цель ссылки — это просто текст, созданный ядром :, это может быть что-то вроде /foo/bar (deleted)для FD, который все еще открыт в файле после того, как он был разъединен. Но open()по этому пути /procпо-прежнему будет открывать фактический файл. (Как и большинство системных вызовов, openследует символическим ссылкам внутри. Для обычных символических ссылок в обычных файловых системах цель ссылки обрабатывается как обычный путь.)

Невозможно связать этот индекс обратно с файловой системой (в основном из соображений безопасности;возможно использование linkat(2)на FD, открытом с помощью O_TMPFILE, у которого никогда не было имени пути в первую очередь.https://stackoverflow.com/questions/4171713/relinking-an-anonymous-unlinked-but-open-file)


В вашем случае правильный вопрос звучит так: «Как было решено, какие системные -вызовы должны что делать с вещами в /proc/PID?»

Насколько я знаю, никакие системные вызовы файлов /procне могут изменить среду процесса. то есть информация о ядре экспортируется только для чтения -.

Вам придется использовать другие хаки, подобные описанным в комментариях, для выполнения системных вызовов типа dup2внутри контекста процесса. например. используя ptraceAPI. например. с помощью GDB или других отладчиков, использующих ptraceдля работы внутри целевого процесса.

4
27.01.2020, 21:48

Why for e.g. Linux it was not implemented that users can change those links manually via ln -s in bash?

Потому что файловая система procпросто показывает внутреннее состояние ядра. В некоторых случаях вы действительно можете влиять на состояние ядра, записывая данные в определенные файлы, но я не могу вспомнить ни одного примера, в котором вы могли бы что-то перемещать.

Would it be difficult to implement?

Ядро с открытым исходным кодом, посмотрите и решите сами ("сложно" будет связано с вашим опытом программирования ).

Также подумайте о том, что должно произойти, если процесс, который вы модифицируете, находится в процессе записи чего-либо в стандартный вывод. Также подумайте о последствиях для безопасности.

Однако, по моей оценке, шансы получить такую ​​модификацию в основном ядре довольно малы.

How was it decided what utility should work with proc - by programmers of that utility?

/proc— это виртуальная файловая система, которая реализует функции ядра, необходимые для виртуальной файловой системы. Когда различные программисты ядра используют /proc, они обычно пытаются сделать это так, чтобы программировать было с наименьшими усилиями.

10
27.01.2020, 21:48

В Linux стандартные файловые дескрипторы ввода/вывода создаются через системные вызовы ядра, а не через файловую систему /proc.

Символические ссылки, которые вы видите в /proc, не являются фактическими средствами, используемыми для передачи данных, а скорее отражением того, что делает ядро, чтобы предоставить процессам доступ к данным. Вот почему вы не можете использовать ln -sдля их изменения.

Что касается вашего вопроса о перенаправлении вывода на лету, я не знаю команды, которая это делает. Но это, безусловно, возможно. Вот пример того, как можно разработать такую ​​программу:

  1. Во-первых, начните с реализации функциональности cat. Следовательно, возьмите стандартный ввод и выгрузите его на стандартный вывод. Это будет не -интерактивное приложение.
  2. Далее,изменить программу так, чтобы она была интерактивной. Простым примером может быть передача небольшого количества ввода и ожидание нажатия пользователем клавиши ВВОД. Затем перенесите еще немного ввода и повторите. На этом этапе программа может останавливаться и принимать решения, что важно для возможности перенаправить вывод на лету.
  3. Наконец, измените программу, чтобы она могла принимать команды, определяющие, какими должны быть входные и выходные данные. Это может быть процесс-демон с API, пользовательским интерфейсом NCURSES и т. д.

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

6
27.01.2020, 21:48

Вместо того, чтобы изменять точку ввода и т. д., вы можете создать псевдо--терминал (PTY)и перенаправить ввод и вывод через него, чтобы программа не знала об этом. что что-то изменилось :на самом деле, есть несколько программ, которые делают именно то, что (часто называюттерминальными мультиплексорами.)

Как вы, вероятно, знаете, вы можете отключиться от сеанса на одном терминале и снова подключиться к нему где-то еще, используя мультиплексор, такой как tmux, но вы также можете в любое время настроить передачу стандартного ввода или вывода. Например, если у меня есть оболочка, работающая внутри панели tmux, и я отправлю команду pipe-pane 'cat >>~/test.txt'(, взятую из справочной страницы ), на tmux, стандартный вывод теперь будет добавлен к ~/test.txtбез изменения что-нибудь внутри панели сеанса.

6
27.01.2020, 21:48

Основное недоразумение здесь, по-видимому, заключается в том, что изменение символической ссылки во время ее записи изменит что-либо ожидаемым образом.

Нет. Как только будет открыт фактический файл (, устройство или канал ), все действия будут относиться к открытому файлу, игнорируя все, что происходит, например, с символической ссылкой, указывающей на него. На самом деле, это не ограничивается символическими ссылками, но в равной степени относится и к «жестким» ссылкам, которые вообще заставляют файлы иметь имена :. В unixoid-системах вы можете перемещать или даже удалять (! )файл (НЕ :Перезаписывать! )что какой-то процесс был открыт, и процесс не увидит никаких изменений, пока не закроет файл.

1
27.01.2020, 21:48

Символическая ссылка — это просто помощник для поиска фактического файла, который на самом деле является помощником для поиска фактического индексного дескриптора. После этого то, что вы открываете, определяется самим инодом. В случае /dev/pts/1вы фактически открываете символьное устройство со старшим номером устройства 136 и младшим 1.

С этого момента имена файлов, наличие файлов или символические ссылки не имеют значения, точно так же, как вы можете получить доступ к файлу, который был удален, если вы открыли его до того, как он был удален.

1
27.01.2020, 21:48

Теги

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