Я не думаю, что я полностью понимаю, что вы спрашиваете ... Пожалуйста, добавьте некоторые объяснения.
Но из того, что я думаю, я понимаю, нет.
Аналогия может быть:
Если я смотрю Лицо А и вижу, с кем они разговаривают, могу ли я определить намерения Лица А?
В этом случае этот ответ довольно темный. Возможно, вы сможете увидеть, что Человек А разговаривает с каким-то важным человеком в правоохранительных органах, и, возможно, с некоторыми людьми, связанными с организованной преступностью. Но это будет чрезвычайно сложно (невозможно?) точно указать мотивы личности А. Являются ли они тайным полицейским или преступником с судьей под большим пальцем?
Вы не можете достоверно прочитать что-либо в одно только такое знание.
Если вам удалось получить больше информации, например, о выполняемых операциях ввода-вывода, вы бы смогли лучше понять ситуацию.
Другими словами, если вы посмотрите на каждый файл (представленный дескрипторами файлов в соответствующем порядке, например, 0-X), он скажет вам природу процесса и / или подпроцессов?
Я думаю, вы несколько озадачены тем, что такое « файловый дескриптор ». Файловый дескриптор идентифицируется простым числом (int) - возвращаемым значением open() ... но внутри ядра файловый дескриптор имеет информацию, связанную с ним. Смотрите struct file .
Я полагаю, что ответ был бы да, если действительно, весь процесс действительно сделан только из этих файлов.
Это также содержит некоторые доказательства неправильного понимания. Процесс не " сделан только из этих файлов ", а вместо этого получает доступ к этим файлам прямо сейчас. Мы можем показать это, выполнив следующее:
$ ls -l /proc/self/fd
total 0
lrwx------ 1 attie attie 64 May 20 15:20 0 -> /dev/pts/3
lrwx------ 1 attie attie 64 May 20 15:20 1 -> /dev/pts/3
lrwx------ 1 attie attie 64 May 20 15:20 2 -> /dev/pts/3
lr-x------ 1 attie attie 64 May 20 15:20 3 -> /proc/13103/fd
Как указал @grawity в комментарии, open() вернет следующий свободный файловый дескриптор, заполняя любые пробелы с нуля. То, что вы видите выше, является снимком файлов, которые в данный момент открыты и со временем изменятся.
Вы не можете увидеть двоичный файл ls в приведенном выше списке или его непосредственные зависимости:
$ ldd $(which ls)
linux-vdso.so.1 => (0x00007fff569ef000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007feeb33df000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007feeb31d7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feeb2e0e000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007feeb2bd0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feeb29cc000)
/lib64/ld-linux-x86-64.so.2 (0x00007feeb361a000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007feeb27c6000)
Когда вы пытаетесь « выполнить ls », компоновщик на самом деле читает файлы библиотеки для сопоставления и «связывания» полного образа процесса. К тому времени, когда ls начинает выполняться, эти данные уже находятся в памяти, и файлы больше не «открываются».
Некоторые приложения могут использовать «плагины» или «динамически» загружать дополнительные файлы, которые предоставляют функциональность (см. dlopen()), но это крайний случай и далек от типичного поведения - ни один из процессов, запущенных на моем компьютере, не имеет файл общего объекта (*.so) открыт.
В итоге, и все еще в согласии с моим первоначальным ответом, нет.
Нет определенного способа определить поведение процесса, посмотрев, какие файлы у него открыты.
Что касается определения природы подпроцесса, это невозможно. Можете ли вы взглянуть на init и определить полную конфигурацию системы во время выполнения? Нет
