Как реализовать процессы, зависящие друг от друга?

Question

[synapse_people]

Нужно запустить 1 главный процесс, который контролирует множество чилд-процессов..
Он запускает каждый подпроцесс в виде bash -c #CMD#&, получается они работают как таски в текущей сессии. Так вот, #CMD# падает, если завершить главный процесс (логично), но не падает, если убить баш.
Вопрос: можно ли сделать так, чтобы в баше тоже была своя сессия (или как ?), чтобы при убивании главного процесса ИЛИ баша , падало CMD следом за ними?
Иерархия такая: MAINPROC -> BASH -> CMD
вот если сделать kill MAINPROC - должен упасть BASH, а за ним CMD (по логике) - так и происходит, все они ложатся.
Но если убить BASH, то MAIN+CMD все еще работают!
setsid пробовал, тогда если убиваешь BASH+MAINPROC - CMD все дальше себе работает и все, без- них в новой сессии....
Как мне сделать это поведение ?
Подробнее, как сейчас:

7434 pts/0    Ss   00:00:00 bash
16491 pts/0    S    00:00:00  \_ bash
18549 pts/0    S+   00:00:00      \_ php ./...php
18553 pts/0    S+   00:00:00 /bin/bash /tmp/CMDt8sL0c
18559 pts/0    Sl+  00:00:18  \_ /CMD

shift196@debian:/srv/$ kill 18553

shift196@debian:/srv/$ ps --forest -o pid,tty,stat,time,cmd -g 
  PID TT       STAT     TIME CMD
16726 pts/1    Ss   00:00:00 bash
18763 pts/1    R+   00:00:00  \_ ps --forest -o pid,tty,stat,time,cmd -g
 7434 pts/0    Ss   00:00:00 bash
16491 pts/0    S    00:00:00  \_ bash
18549 pts/0    S+   00:00:00      \_ php ./...php
18559 pts/0    Sl+  00:00:20 /CMD

Но CMD не упала,она дальше себе работает!

Comments

[synapse_people]

PID  PPID TT       STAT     TIME CMD
 7434  2957 pts/0    Ss   00:00:00 bash
16491  7434 pts/0    S    00:00:00  \_ bash
18549 16491 pts/0    S+   00:00:00      \_ php ./php
19136  1971 pts/0    S+   00:00:00 /bin/bash /tmp/CMDQJCuRm
19142 19136 pts/0    Sl+  00:00:19  \_ /cmd

[synapse_people]

synapse_people,

shift196  1971  0.0  0.0  65056  6656 ?        Ss   09:49   0:00 /lib/systemd/systemd --user

Answer 1

[Saboteur]

По логике как раз и не должны фоновые процессы падать, если убит баш.
Об этом и говроит ваш & в конце строки: bash -c #CMD#&

Процессы могут завершаться, если им посылается конкретный сигнал. В группе процессов, сигнал посланный главному процессу также отправляется всем дочерним.
Но в вашем случае в связке: MAIN -> BASH -> CMD вы сами отвязываете дочерний процесс CMD от процесса BASH командой &
При этом MAIN все еще является лидером всей группы процессов, поэтому завершение MAIN влияет на все дочерние.

Comments

[synapse_people]

сейчас MAIN генерит bash-скрипт, который запускает CMD.
CMD "висячий" процесс, т.е. нормальный.. т.е. пока он работает, строки после него в баш-скрипте не выполняются (т.е. блокирует пока не завершится).
вот и получается, MAIN запускает скрипт вот так:
/tmp/script.sh&>/dev/null&
по сути создается дочерний процесс BASH, выполняющий сгенеренный скрипт, в котором команда для запуска условного CMD (команд в скрипте сотни, но интересует именно реальная CMD, которая делает работу).. Вот этот дочерний BASH должен быть бэкграунд процессом к MAIN, разве не так?
MAIN запускает херову тучу таких вот дочерних себе CMD , работающих в bash'ах.
Как можно иначе запустить 2 процесса без добавления & ?
все равно не понимаю, почему убийство bash не приводит к завершению работы команд в нем?..

[synapse_people]

Как запустить скрипт так, чтобы он не блокировал выполнение в MAIN (процесс пхп только 1 поток и вызов шелл скрипта без & и перенаправления в дев нул его блочит, пока скрипт не завершится), и так, чтобы при убийстве скрипта, завершались его процессы, а при убийстве MAIN - все скрипты и их подпроцессы тоже?
Спасибо за совет

[Saboteur]

"&" запускает дочерний процесс в отдельной process group, следовательно убив parent процесс для этой группы, вы группу не убиваете. Нужно убивать лидера группы, чтобы сигнал был послан всем процессам.

Можно делать так:
main -> bash & -> cmd
тогда bash запущенный с & создаст отдельную группу, а cmd запускайте в этом баш без &
Но при этом убийство main не вызовет завершение всех bash ;)

Можно сохранять PID каждого bash процесса в файл, и добавить команду killmain, которую будете вызывать для завершения всех bash процессов.

[synapse_people]

Saboteur, да хотелось бы переложить на ОС , а не городить в проге костыли с сохранением всех PID

[Saboteur]

чтобы при убийстве скрипта, завершались его процессы, а при убийстве MAIN - все скрипты и их подпроцессы тоже?

Ну видимо на скриптовом уровне никак. Многопоточность в баш не реализована, есть только асинхронное выполнение coproc или & в бэкграунде, что не одно и тоже.

Контроль зомби процессов обычно делают через PID файлы, но это не для решения многопоточного выполнения. Это решение для гарантированного запуска процесса в одном экземпляре.

[Saboteur]

synapse_people,

хотелось бы переложить на ОС

баш же OC-независимый, он и на винде и на маке и на линуксе и на юниксе =)

Надо писать софт с использованием ос-функций на каком-нить C.
Cпособа реализовать fork через баш нельзя, все упоминания сводятся именно к &, что не есть системный fork.

[synapse_people]

Saboteur, вот и вопрос, на серве при убийстве MAIN потомки не гасятся в след, продолжают работать с PGID=1
и там и там DEBIAN 9.9
вообще ничего не понимаю....

[synapse_people]

Saboteur, а есть разница между ./script.sh в котором#!/bin/bash
и bash -c ?

[Saboteur]

в первом случае для файла script.sh должны быть права на выполнение (executable bit) и выполнится именно /bin/bash

во втором случае выполнится тот баш, который первый будет в PATH (вдруг это будет /usr/bin/bash) =)

Но это я уже докапываюсь. В общем случае нет разницы.

[Saboteur]

synapse_people,

вот и вопрос, на серве при убийстве MAIN потомки не гасятся в след, продолжают работать с PGID=1
и там и там DEBIAN 9.9

Ну так и не должны. через & вы полностью отвязываете процесс от парента.
Если теряется текущий парент, а процессу не послан сигнал на завершение, он просто меняет парент на init (первый процесс)

[synapse_people]

Saboteur, ок, теперь еще все хуже.
Я переделал MAIN, теперь он работает без &,он просто через exec дергает скрипт.
Сначала форкается, затем ставит setsid себе
Потом еще много раз форкается уже с sid для каждого exec скрипта
Получается при выводе все процессы в виде дерева, это ок, у них одна группа, это ок.
Убиваю лидера, потомки все равно работают
Почему ?
& нет

[synapse_people]

Saboteur, Как-то можно переконфигурировать что-то, чтобы при завершении , валилась полностью вся цепь? а не перебрасывал на init?

[Saboteur]

synapse_people,
Как я это понимаю - сделать process group через скрипты - нельзя, но я не системный программист, я больше по скриптам и башу.
у вас MAIN это скрипт или бинарник?
Если вы разработчик, почитайте https://en.wikipedia.org/wiki/Process_group, может что-то станет понятнее.

Answer 2

[q2zoff]

Вопрос: можно ли сделать так, чтобы в баше тоже была своя сессия (или как ?), чтобы при убивании главного процесса ИЛИ баша , падало CMD следом за ними?

Проблема в том, что вы используете "костыли" для создания дочерних процессов. Используйте системный вызов fork напрямую в своем коде, а не делегируйте это bash.

А вообще, обратите внимание на сисколы setpgid и setpgrp. Можно BASH вынести в отдельную группу, и тогда завершение работы как MAIN так и BASH (с помощью сигнала) приведет к завершению CMD. В первом случае будут завершены все дочерние процессы, т.к. прекратит работу лидер сессии MAIN. Во втором случае будут завершены BASH и CMD, т.к. являются членами одной группы, отличной от группы MAIN. Надеюсь, что понятно изложил свои мысли.

Comments

[synapse_people]

Да, достаточно понятно..
А в чем разница "setpgid и setpgrp"?

[synapse_people]

первый есть
https://www.php.net/manual/en/function.posix-setpg...
а второй не нашел..

[q2zoff]

synapse_people, setpgrp() эквивалентно setpgid(0,0). Не уверен, что оба сискола присутствуют в php.

Если из bash вызвать setpgid(0, 0), то это вынесет bash в отдельную группу, присвоив ей в качестве идентификатора PID bash'a (читай новый уникальный идентификатор группы). Затем из bash'а вызовите CMD. Должно все получиться. Сам я с семейством этих функций не работал, поэтому только теоретические знания.