Get child pid linux

How do I get the parent process ID of a given child process?

How to get parent PID from a given child’s PID?

I know I can manually check it under /proc , I wonder if there is a smart/better way to achieve this in Ubuntu. Note the parent may or may not be killed.

4 Answers 4

How to get a parent PID (PPID) from a child’s process ID (PID) using the command-line

• e.g. ps -o ppid= 2072 returns 2061 , which you can easily use in a script etc. ps -o ppid= -C foo gives the PPID of process with command foo . You can also use the old fashioned ps | grep : ps -eo ppid,comm | grep ‘[f]oo’ .
• Fuller explanation: ps -f 2072 returns
• The pstree relation is: pstree -s -p 2072 :

Using only shell variable to get parent PID :

if you need the command from this parent pid:

if you need the full command line (with all options):

Explanation

• $PPID is defined by the shell, it’s the PID of the parent process
• in /proc/ , you have some dirs with the PID of each processes. Then, if you cat /proc/$PPID/comm , you echo the command name of the PID

Check man proc

Using pstree by command name

Using pstree you can search by the child process name and get the Process ID (PID) along with the parents, grandparents and any children of the child process:

In this case sleep is the child command and it’s PID is 8414 . It’s parent ID is 841 and is called display-auto-brightness . The grandparent is a shell ( sh ) with a process ID of 839 . The great-grandparent is cron with a process ID of 795 . The great-great-grandparent is also cron with a process ID of 763 .

If you want to search by Process ID of sleep instead of name you can use:

Notice the sleep process ID changed to 14653 . The parent (PID 841) sleeps for 1 minute, wakes up for a split second and then starts a new sleep command which gets a new process ID. This is another reason why searching for sleep is easier than searching by process ID.

To see a nested chain all the way back to boot process use the PID instead of name:

Note: Another minute has passed and the sleep command gets a new PID (8541).

Источник

ps: How can i recursively get all child process for a given pid

How can I get the entire process tree spawned by a given process displayed as a tree and only that tree i.e. no other processes?

The output could e.g. look like

I couldn’t get the desired result purely with parameters to ps .

The following gives the desired result but seems a bit involved:

Does anyone have an easier solution?

13 Answers 13

The pstree is a very good solution, but it is a little bit reticent. I use ps —forest instead. But not for a PID ( -p ) because it prints only the specific process, but for the session ( -g ). It can print out any information ps can print in a fancy ASCII art tree defining the -o option.

So my suggestion for this problem:

If the process is not a session leader, then a little bit more trick has to be applied:

This gets the session id (SID) of the current process first and then call ps again with that sid.

If the column headers are not needed add a ‘=’ after each column definition in ‘-o’ options, like:

An example run and the result:

Unfortunately this does not work for screen as it sets the sid for each child screen and all grandchild bash.

To get all the processes spawned by a process the whole tree needs to be built. I used awk for that. At first it builds a hash array to contain all PID => ,child,child. . At the end it calls a recursive function to extract all the child processes of a given process. The result is passed to another ps to format the result. The actual PID has to be written as an argument to awk instead of

For a SCREEN process (pid=8041) the example output looks like this:

Источник

How to get process ID of background process?

I start a background process from my shell script, and I would like to kill this process when my script finishes.

How to get the PID of this process from my shell script? As far as I can see variable $! contains the PID of the current script, not the background process.

8 Answers 8

You need to save the PID of the background process at the time you start it:

You cannot use job control, since that is an interactive feature and tied to a controlling terminal. A script will not necessarily have a terminal attached at all so job control will not necessarily be available.

You can use the jobs -l command to get to a particular jobL

In this case, 46841 is the PID.

-l Report the process group ID and working directory of the jobs.

jobs -p is another option which shows just the PIDs.

• $$ is the current script’s pid
• $! is the pid of the last background process

Here’s a sample transcript from a bash session ( %1 refers to the ordinal number of background process as seen from jobs ):

An even simpler way to kill all child process of a bash script:

The -P flag works the same way with pkill and pgrep — it gets child processes, only with pkill the child processes get killed and with pgrep child PIDs are printed to stdout.

. So at least it shows something, but this is probably not the output of pgrep`

this is what I have done. Check it out, hope it can help.

Then just run it as: ./bgkill.sh with proper permissions of course

You might also be able to use pstree:

This typically gives a text representation of all the processes for the «user» and the -p option gives the process-id. It does not depend, as far as I understand, on having the processes be owned by the current shell. It also shows forks.

pgrep can get you all of the child PIDs of a parent process. As mentioned earlier $$ is the current scripts PID. So, if you want a script that cleans up after itself, this should do the trick:

I have run into this problem many times provisioning various infrastructure objects. Many times you need a temp proxy using kubectl or a temp port forward. I have found the timeout command to be a good solution for these, since it allows my script to be self contained and I can be assured that the process will end. I try to set small timeouts and rerun the script if I need still need it.

Источник

Get child pid linux

Эта глава открывает большую и очень важную для Linux-программиста тему многозадачности. Описать все сразу не получится, поэтому мы будем неоднократно возвращаться к многозадачности в последующих главах книги. Пристегните ремни покрепче!

Наберите в своей оболочке следующую команду:

На экран будут выведен список всех работающих в системе процессов. Если хотите посчитать количество процессов, наберите что-нибудь, набодобие этого:

Первое число — это количество работающих в системе процессов. Пользователи KDE могут воспользоваться программой kpm, а пользователи Gnome — программой gnome-system-monitor для получения информации о процессах. На то он и Linux, чтобы позволять пользователю делать одно и то же разными способами.

Возникает вопрос: «Что такое процесс?». Процессы в Linux, как и файлы, являются аксиоматическими понятиями. Иногда процесс отождествляют с запущенной программой, однако это не всегда так. Будем считать, что процесс — это рабочая единица системы, которая выполняет что-то. Многозадачность — это возможность одновременного сосуществования нескольких процессов в одной системе.

Linux — многозадачная операционная система. Это означает что процессы в ней работают одновременно. Естественно, это условная формулировка. Ядро Linux постоянно переключает процессы, то есть время от времени дает каждому из них сколько-нибудь процессорного времени. Переключение происходит довольно быстро, поэтому нам кажется, что процессы работают одновременно.

Одни процессы могут порождать другие процессы, образовывая древовидную структуру. Порождающие процессы называются родителями или родительскими процессами, а порожденные — потомками или дочерними процессами. На вершине этого «дерева» находится процесс init, который порождается автоматически ядром в процесссе загрузки системы.

К каждому процессу в системе привязана пара целых неотрицательных чисел: идентификатор процесса PID (Process IDentifier) и идентификатор родительского процесса PPID (Parent Process IDentifier). Для каждого процесса PID является уникальным (в конкретный момент времени), а PPID равен идентификатору процесса-родителя. Если ввести в оболочку команду ps -ef, то на экран будет выведен список процессов со значениями их PID и PPID (вторая и третья колонки соотв.). Вот, например, что творится у меня в системе:

Надо отметить, что процесс init всегда имеет идентификатор 1 и PPID равный 0. Хотя в реальности процесса с идентификатором 0 не существует. Дерево процессов можно также пресставить в наглядном виде при помощи опции —forest программы ps:

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

6.2. Использование getpid() и getppid()

Процесс может узнать свой идентификатор (PID), а также родительский идентификатор (PPID) при помощи системных вызовов getpid() и getppid().

Системные вызовы getpid() и getppid() имеют следующие прототипы:

Для использования getpid() и getppid() в программу должны быть включены директивой #include заголовочные файлы unistd.h и sys/types.h (для типа pid_t). Вызов getpid() возвращает идентификатор текущего процесса (PID), а getppid() возвращает идентификатор родителя (PPID). pid_t — это целый тип, размерность которого зависит от конкретной системы. Значениями этого типа можно оперировать как обычными целыми числами типа int.

Рассмотрим теперь простую программу, которая выводит на экран PID и PPID, а затем «замирает» до тех пор, пока пользователь не нажмет .

Проверим теперь, как работает эта программа. Для этого откомпилируем и запустим ее:

Теперь, не нажимая , откроем другое терминальное окно и проверим, правильность работы системных вызовов getpid() и getppid():

6.3. Порождение процесса

Как уже говорилось ранее, процесс в Linux — это нечто, выполняющее программный код. Этот код называют образом процесса (process image). Рассмотрим простой пример, когда вы находитесь в оболочке bash и выполняете команду ls. В этом случае происходит следующее. Образ программы-оболочки bash выполняется в процессе #1. Затем вы вводите команду ls, и оболочка определяет, что нужно запустить внешнюю программу (/bin/ls). Тогда процесс #1 создает свою почти точную копию, процесс #2, который выполняет тот же самый программный код. После этого процесс #2 заменяет свой текущий образ (оболочку) другим образом (программой /bin/ls). В итоге получаем отдельный процесс, выполняющий отдельную программу.

«К чему такая путаница?» — спросите вы. Зачем сначала «клонировать» процесс, а затем заменять в нем образ? Не проще ли все делать одной-единственной операцией? Ответы на подобные вопросы дать тяжело, но, как правило, с опытом прихоидит понимание того, что подобная схема является одной из граней красоты Unix-систем.

Попробуем все-таки разобраться, почему в Unix-системах порождение процесса отделено от запуска программы. Для этого выясним, что же происходит с данными при «клонировании» процесса. Итак, каждый процесс хранит в своей памяти различные данные (переменные, файловые дескрипторы и проч.). При порождении нового процесса, потомок получает точную копию данных родителя. Но как только новый процесс создан, родитель и потомок уже распоряжаются своими копиями по своему усмотрению. Это позволяет распараллелить программу, заставив ее выполнять какой-нибудь трудоемкий алгоритм в отдельном процессе.

Может быть кто-то из вас слышал про то, что в Linux есть потоки, которые позволяют в одной программе реализовывать параллельное выполнение нескольких функций. Опять же возникает вопрос: «Если есть потоки, зачем вся эта головомойка с клонированиями и заменой образов?». А дело в том, что потоки работают с общими данными и выполняются в одной программе. Если в потоке произошло что-то страшное, то это, как правило, отражается на всей программе в целом. Хотя технически потоки реализованы в Linux на базе процессов, но процесс все же является более независимой единицей. Крах дочернего процесса никак не отражается на работе родителя, если сам родитель этого не пожелает.

По правде сказать, программисты редко прибегают к методике распараллеливания одной программы при помощи процессов. Но суть в том, что в Unix-системах программист обладает полной свободой выбора стратегии многозадачности. И это здорово!

Разберемся теперь с тем, как на практике происходит «клонирование» процессов. Для этого используется простой системный вызов fork(), прототип которого находится в файле unistd.h:

Если fork() завершается с ошибкой, то возвращается -1. Это редкий случай, связанный с нехваткой памяти или превышением лимита на количество процессов. Но если разделение произошло, то программе нужно позаботиться об идентификации своего «Я», то есть определении того, где родитель, а где потомок. Это делается очень просто: в родительский процесс fork() возвращает идентификатор потомка, а потомок получает 0. Следующий пример демонстрирует то, как это происходит.

Проверяем, что получилось:

Обратите внимание, что поскольку после вызова fork() программу выполняли уже два независимых процесса, то сообщение родителя вполне могло бы появиться первым.

6.4. Замена образа процесса

Итак, теперь мы умеем порождать процессы. Научимся теперь заменять образ текущего процесса другой программой. Для этих целей используется системный вызов execve(), который объявлен в заголовочном файле unistd.h вот так:

Все очень просто: системный вызов execve() заменяет текущий образ процесса программой из файла с именем path, набором аргументов argv и окружением envp. Здесь следует только учитывать, что path — это не просто имя программы, а путь к ней. Иными словами, чтобы запустить ls, нужно в первом аргументе указать «/bin/ls».

Массивы строк argv и envp обязательно должны заканчиваться элементом NULL. Кроме того, следует помнить, что первый элемент массива argv (argv[0]) — это имя программы или что-либо иное. Непосредственные аргументы программы отсчитываются от элемента с номером 1.

В случае успешного завершения execve() ничего не возвращает, поскольку новая программа получает полное и безвозвратное управление текущим процессом. Если произошла ошибка, то по традиции возвращается -1.

Рассмотрим теперь пример программы, которая заменяет свой образ другой программой.

Итак, данная программа выводит свой PID и передает безвозвратное управление программе cat без аргументов и без окружения. Проверяем:

Программа вывела идентификатор процесса и замерла в смиренном ожидании. Откроем теперь другое терминальное окно и проверим, что же творится с нашим процессом:

Итак, мы убедились, что теперь процесс 30150 выполняет программа cat. Теперь можно вернуться в исходное окно и нажатием Ctrl+D завершить работу cat.

И, наконец, следующий пример демонстрирует запуск программы в отдельном процессе.

Обратите внимание, что поскольку execve() не может возвращать ничего кроме -1, то для обработки возможной ошибки вовсе не обязательно создавать ветвление. Иными словами, если вызов execve() возвратил что-то, то это однозначно ошибка.

Источник