- это PID детского процесса всегда больше, чем PID его родителя на Linux?
Решение @ Herbert, вероятно, самое простое, но вы также можете использовать поисковые запросы:
$ grep -Poz '(?<=:MENU1\n)[^:]*' file
0. public
1. admin
2. webmail
Нет, по той простой причине, что существует максимальное числовое значение, которое может иметь PID. Если процесс имеет самый высокий PID, ни один из его потомков не может иметь более высокий PID. Альтернативой тому, чтобы дать ребенку более низкий PID, было бы полное проваливание fork(), что было бы не очень продуктивно.
Идентификаторы PID распределяются по порядку, и после использования старшего из них система переключается на повторное использование (свободных )младших, так что вы можете получить более низкие PID для дочерних элементов и в других случаях.
Максимальный PID по умолчанию в моей системе(/proc/sys/kernel/pid_max)составляет всего 32768, так что нетрудно достичь условия, при котором происходит циклический переход.
$ echo $$
27468
$ bash -c 'echo $$'
1296
$ bash -c 'echo $$'
1297
Если бы ваша система распределяла идентификаторы PID случайным образом (, как это делает OpenBSD ), а не последовательно (, как в Linux ), было бы два варианта. Либо случайный выбор был сделан по всему пространству возможных PID, и в этом случае было бы очевидно, что PID ребенка может быть ниже, чем PID родителя. Или дочерний PID будет выбран случайным образом из значений, превышающих PID родителя, что в среднем поместит его посередине между PID родителя и максимальным. Затем рекурсивно разветвляющиеся процессы быстро достигнут максимума, и мы окажемся в той же точке, что и упомянутая выше :: новому форку для успеха потребуется использовать более низкий PID.
Также существует вероятность уязвимостей в системе безопасности, использующих уведомления ядра и разветвляющихся, чтобы избежать обнаружения при сканировании таблицы процессов; это, если все сделано правильно, приводит к тому, что ваш процесс имеет более низкий PID, а инструменты процесса не видят рассматриваемый процесс.
http://cve.circl.lu/cve/CVE-2018-1121
procps-ng, procps is vulnerable to a process hiding through race condition. Since the kernel's proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration. An unprivileged attacker can hide a process from procps-ng's utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.