Каждый поток, кроме первого (init ), имеет родительский поток. Вы можете лучше всего увидеть взаимосвязь, используя флаг f для ps, таким образом :"ps faux" (без кавычек ).
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
внутри контекста процесса. например. используя ptrace
API. например. с помощью GDB или других отладчиков, использующих ptrace
для работы внутри целевого процесса.
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
, они обычно пытаются сделать это так, чтобы программировать было с наименьшими усилиями.
В Linux стандартные файловые дескрипторы ввода/вывода создаются через системные вызовы ядра, а не через файловую систему /proc
.
Символические ссылки, которые вы видите в /proc
, не являются фактическими средствами, используемыми для передачи данных, а скорее отражением того, что делает ядро, чтобы предоставить процессам доступ к данным. Вот почему вы не можете использовать ln -s
для их изменения.
Что касается вашего вопроса о перенаправлении вывода на лету, я не знаю команды, которая это делает. Но это, безусловно, возможно. Вот пример того, как можно разработать такую программу:
cat
. Следовательно, возьмите стандартный ввод и выгрузите его на стандартный вывод. Это будет не -интерактивное приложение. Вышеизложенное, безусловно, легче сказать, чем сделать. Я упустил множество важных деталей, но думаю, этого достаточно, чтобы показать, что перенаправление вывода на лету, по крайней мере, осуществимо.
Вместо того, чтобы изменять точку ввода и т. д., вы можете создать псевдо--терминал (PTY)и перенаправить ввод и вывод через него, чтобы программа не знала об этом. что что-то изменилось :на самом деле, есть несколько программ, которые делают именно то, что (часто называюттерминальными мультиплексорами.)
Как вы, вероятно, знаете, вы можете отключиться от сеанса на одном терминале и снова подключиться к нему где-то еще, используя мультиплексор, такой как tmux
, но вы также можете в любое время настроить передачу стандартного ввода или вывода. Например, если у меня есть оболочка, работающая внутри панели tmux
, и я отправлю команду pipe-pane 'cat >>~/test.txt'
(, взятую из справочной страницы ), на tmux
, стандартный вывод теперь будет добавлен к ~/test.txt
без изменения что-нибудь внутри панели сеанса.
Основное недоразумение здесь, по-видимому, заключается в том, что изменение символической ссылки во время ее записи изменит что-либо ожидаемым образом.
Нет. Как только будет открыт фактический файл (, устройство или канал ), все действия будут относиться к открытому файлу, игнорируя все, что происходит, например, с символической ссылкой, указывающей на него. На самом деле, это не ограничивается символическими ссылками, но в равной степени относится и к «жестким» ссылкам, которые вообще заставляют файлы иметь имена :. В unixoid-системах вы можете перемещать или даже удалять (! )файл (НЕ :Перезаписывать! )что какой-то процесс был открыт, и процесс не увидит никаких изменений, пока не закроет файл.
Символическая ссылка — это просто помощник для поиска фактического файла, который на самом деле является помощником для поиска фактического индексного дескриптора. После этого то, что вы открываете, определяется самим инодом. В случае /dev/pts/1
вы фактически открываете символьное устройство со старшим номером устройства 136 и младшим 1.
С этого момента имена файлов, наличие файлов или символические ссылки не имеют значения, точно так же, как вы можете получить доступ к файлу, который был удален, если вы открыли его до того, как он был удален.