Для какого процесса нужен / proc / self /?

Это не имеет ничего общего с процессами переднего и заднего плана; это связано только с текущим запущенным процессом. Когда ядро ​​должно ответить на вопрос «На что указывает / proc / self ?», Оно просто выбирает текущий запланированный pid , т.е. текущий процесс (на текущем логическом ЦП). В результате / proc / self всегда указывает на pid запрашивающей программы; если вы запустите

ls -l /proc/self

, вы увидите pid ls , если вы напишете код, который использует / proc / self , этот код будет видеть свой собственный pid и т. д.

Это какой бы процесс не обращался к /proc/self или файлам/папкам в нем.

Попробуйте cat /proc/self/cmdline. Вы получите, сюрприз-сюрприз, cat /proc/self/cmdline, (на самом деле, вместо пробела будет нулевой символ между t и /), потому что это будет процесс cat, обращающийся к этому псевдофайлу.

Когда вы выполните ls -l /proc/self, вы увидите pid самого процесса ls. Или как насчет ls -l /proc/self/exe; это укажет на исполняемый файл ls.

Или попробуйте для разнообразия:

$ cp /proc/self/cmdline /tmp/cmd
$ hexdump -C /tmp/cmd
00000000  63 70 00 2f 70 72 6f 63  2f 73 65 6c 66 2f 63 6d  |cp./proc/self/cm|
00000010  64 6c 69 6e 65 00 2f 74  6d 70 2f 63 6d 64 00     |dline./tmp/cmd.|
0000001f

или даже

$ hexdump -C /proc/self/cmdline 
00000000  68 65 78 64 75 6d 70 00  2d 43 00 2f 70 72 6f 63  |hexdump.-C./proc|
00000010  2f 73 65 6c 66 2f 63 6d  64 6c 69 6e 65 00        |/self/cmdline.|
0000001e

Как я уже сказал, это будет любой процесс, который обращается к /proc/self или находящимся в нем файлам/папкам.

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

По сути, / proc / self / представляет процесс, читающий / proc / self / . Итак, если вы попытаетесь открыть / proc / self / из программы на C, тогда он будет представлять эту программу. Если вы попытаетесь сделать это из оболочки, то это будет оболочка и т. Д.

Но что, если у вас есть четырехъядерный ЦП, способный запускать 4 процесса одновременно, по-настоящему, а не в многозадачном режиме?

Тогда каждый процесс будет видеть разные / proc / self / по-настоящему, не имея возможности видеть / proc / self / друг друга.

Как это работает?

Ну, / proc / self / на самом деле не папка.Это драйвер устройства, который раскрывается как папка, если вы пытаетесь получить к нему доступ. Это потому, что он реализует API, необходимый для папок. Каталог / proc / self / - не единственное, что делает это. Рассмотрите возможность подключения общих папок с удаленных серверов, подключения USB-накопителей или Dropbox. Все они работают за счет реализации одного и того же набора API-интерфейсов, которые заставляют их вести себя как папки.

Когда процесс пытается получить доступ к / proc / self / , драйвер устройства динамически генерирует его содержимое, считывая данные из этого процесса. Таким образом, файлы в / proc / self / на самом деле не существуют. Это что-то вроде зеркала, которое отражает процесс, пытающийся на него взглянуть.

Это действительно драйвер устройства? Похоже, вы слишком упрощаете!

Да, это действительно так. Если вы хотите быть педантичным, это модуль ядра. Но если вы посмотрите сообщения usenet на различных каналах разработчиков Linux, большинство разработчиков ядра используют термины «драйвер устройства» и «модуль ядра» как взаимозаменяемые. Раньше я писал драйверы устройств, эээ ... модули ядра для Linux. Если вы хотите написать свой собственный интерфейс в / proc / , скажем, например, вам нужна файловая система /proc/unix.stackexchange/ , которая возвращает сообщения с этого веб-сайта, вы можете прочитать о том, как сделать это в почтенной книге «Драйверы устройств Linux», опубликованной О'Рейли. Он даже доступен в электронном виде в Интернете.

Тот, который обращается к символической ссылке (вызывает readlink () для нее или open () на пути через нее). В то время он будет работать на процессоре, но это не имеет значения. В многопроцессорной системе может одновременно выполняться несколько процессов на ЦП.

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

/ proc / self - это синтаксический сахар. Это ярлык для соединения / proc / и результата системного вызова getpid () (доступного в bash как метапеременная $$). Это может сбивать с толку, хотя в случае сценариев оболочки, поскольку многие из операторов вызывают другие процессы, в комплекте с собственными PID ... PID, которые чаще всего относятся к мертвым процессам. Учтите:

root@vps01:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 Jan  1 01:51 0 -> /dev/pts/0
lrwx------ 1 root root 64 Jan  1 01:51 1 -> /dev/pts/0
lrwx------ 1 root root 64 Jan  1 01:51 2 -> /dev/pts/0
lr-x------ 1 root root 64 Jan  1 01:51 3 -> /proc/26562/fd
root@vps01:~# echo $$
593

'/ bin / ls' будет оценивать путь к каталогу, разрешая его как / proc / 26563, поскольку это PID процесса - вновь созданного процесса / bin / ls - который читает содержимое файла каталог. Но к тому времени, когда следующий процесс в конвейере, в случае сценария оболочки, или к тому времени, когда появится приглашение, в случае интерактивной оболочки путь больше не существует и вывод информации относится к несуществующему процессу.

Это применимо только к внешним командам (тем, которые являются фактическими исполняемыми программными файлами, а не встроены в саму оболочку). Таким образом, вы получите разные результаты, если, скажем, используете подстановку имен файлов для получения списка содержимого каталога, вместо того, чтобы передавать имя пути внешнему процессу / bin / ls:

root@vps01:~# ls /proc/self/fd
0  1  2  3
root@vps01:~/specs# echo /proc/self/fd/*
/proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 /proc/self/fd/255 /proc/self/fd/3

В первой строке оболочка создала новый процесс '/ bin / ls' с помощью системного вызова exec (), передав "/ proc / self / fd" как argv [1]. '/ bin / ls', в свою очередь, открыл каталог / proc / self / fd и прочитал, а затем распечатал его содержимое при итерации по ним.

Во второй строке, однако, негласно используется glob () для расширения списка имен файлов; они передаются как массив строк для эха.(Обычно реализуется как внутренняя команда, но часто есть также двоичный файл / bin / echo ... но эта часть на самом деле не имеет значения, поскольку echo имеет дело только со строками, которые никогда не передаются никаким системным вызовам, связанным с именами путей.)

Теперь рассмотрим следующий случай:

root@vps01:~# cd /proc/self/fd
root@vps01:~# ls
0  1  2  255

Здесь оболочка, родительский процесс для / bin / ls, сделала подкаталог / proc / self своим текущим каталогом . Таким образом, относительные пути оцениваются с его точки зрения. Я предполагаю, что это связано с семантикой файла POSIX, где вы можете создать несколько жестких ссылок на файл, включая любые открытые файловые дескрипторы. Итак, на этот раз / bin / ls ведет себя аналогично echo / proc / $$ / fd / *.

Поскольку shell вызывает программы типа ls в отдельных процессах, /proc/self будет отображаться как symlink на nnnnn, где nnnnn - идентификатор процесса ls. Насколько я знаю, в широко используемых оболочках нет встроенной функции для чтения симлинков, но в Perl она есть:

perl -e 'print "/proc/self link: ",readlink("/proc/self")," - pid $$\n";'

Итак, /proc/self ведет себя как симлинк, но файловая система procfs делает его "волшебным" процессом.