группы процессов...

Я не понял проблемы. Убиваешь процесс БЭ и init за тебя замочит всех его детей.

Ща!
Простите, как тогда вобще демоны работают: два раза форк, теряется связь с терминалом, а дальше процесс гуляет сам по себе, независимо от потомка!

А тк процесс 'А' уже работает как демон, то и одного форка достаточно...

Нифига. Процесс один раз воркается. закрывает все дискрипторы и менет диру. Получается демон.

Предлагаю оставлять pid всех детей в /var/run/A/БЭ_pid.pid далее do{

. . .

}while(...); Если ребёнок созданный БЭ не будет фокатся то етого будет достаточно иначе можешь попробовать подменить ф-ю execv вызываемую всеми потомками процесса А. За небольшим исключением ето сработает

Не катит... Сохранять пид БЭ не нужно - он и так известен...
И подменить системную функцию - это нужно сделать в ядре, подменить системный вызов... Кроме того какой смысл? Потомок может просто наплодить себе подобных без execv - как их тогда пришить.
можно в БЭ создать новый сеанс, тогда все потомки будут в одной группе... А потом пришить группу... Но ведь потомок имеет право сменить группу!

Кстати одним закрытием первых трёх дескрипторов и сменой директории не обойдёшься - будут всё ещё приходить сигналы с управляющего терминала предка... А если два раза сделать форк - тогда уже нет...

>Не катит... Сохранять пид БЭ не нужно - он и так известен...

Не понял. Тебе известен только pid первого фока от А а тебе нужны pid также форков от БЭ о которых А понятия не имеет зато ты можешь указать А где их искать а форкам от Б куда их писать. Так ты их и помиришь.

>И подменить системную функцию - это нужно сделать в ядре, подменить системный вызов...

Ерунда. За тебя уже давно ето сделали. На всех(почти) юниксах системные вызовы подменяются не намного сложнее чем перегрузка оператора new в С++(со всеми аналогиями). Как сделать - когдато читал статью кажись на bugtrack.ru

>Кстати одним закрытием первых трёх дескрипторов и сменой директории не обойдёшься - будут всё ещё приходить сигналы с управляющего терминала предка... А если два раза сделать форк - тогда уже нет...

Кто тебе такое сказал??? Или чё ты имееш ввиду???
Выполни например

startx </dev/null >/dev/null 2>&1
^Z
bg
logout
#Или ^D или чёто аналогичное

И ты увидиш что startx не имеет управляющего терминала + имеет предком init + никак не отреагирует на ^D на родительском управляющем терминале.

ps. кстати можешь установить процессу А какую нибуть переменну окружения а потом искать дочерние процесы в /proc по факту определения етой переменной окружения. Правда никто не помешает дочернему процессу её удалить естественно если он о ней догадается.

setpgid(0,0) в child процессе, тогда его и его потомков
можно убить kill(-PID_OF_CHILD, 9).

> Кстати одним закрытием первых трёх дескрипторов и сменой директории не
> обойдёшься

Верно, закрытие управляющего терминала не освобождает от него.

>> Кстати одним закрытием первых трёх дескрипторов и сменой директории не обойдёшься

>Верно, закрытие управляющего терминала не освобождает от него.

Зато форк после закрытия первых трёх дескрипторов освобождает

cvv wrote:

>>> Кстати одним закрытием первых трёх дескрипторов и сменой директории не обойдёшься

>> Верно, закрытие управляющего терминала не освобождает от него.

>Зато форк после закрытия первых трёх дескрипторов освобождает

Нет. нужен setsid().

1:~$ perl -e 'close STDIN; close STDOUT; close STDERR; fork ? wait : system "ps -o tty $$ > /dev/tty"'
TT
tty1
1:~$

Обьясни поподробнее, а то етот вопрос в прочтённой мною литературе недостаточно освещался.

А если кроме stdin,stdout,stderr закрыть /dev/tty Тогда процес точно останется без управляющего терминала или ещё чёто вылезет???

Кстати а почему ps вместо управляющего терминала /dev/tty показывает '?'

????

да, нужен setsid... или форк два раза, эффект тот же.
Но вопрос - то как выделить всех потомков?
Вобще можно как-то из ядра надыбать дерево процессов начиная с какого-нить ПИДА, тогда всё было бы просто....

> да, нужен setsid... или форк два раза, эффект тот же.

да хоть десять раз форк, не поможет это!

> Но вопрос - то как выделить всех потомков?

Я уже написал выше, как!

так и потомок может сменить группу, тогда его хрен достанешь!

> так и потомок может сменить группу, тогда его хрен достанешь!

Да, тогда не выйдет, конечно. Пардон, пропустил пост,
где сказано, что потомок может поменять группу, в оригинале
говорилось только про setuid().

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

Еще можно убить все процессы этого пользователя, если
это подходит.

Пользователь может сменить uid и gid, запустив чужое приложение.
Тогда читать proc - как? Какие процессы убивать? все, у которых pid больше, чем pid процесса БЭ? Но ведь другие приложения тоже могут наплодить процессы.

Как это сейчас делается - читается proc и уничтожаются все процессы, за исключением процессов, принадлежащих заданным пользователям (то есть как бы привелигированным - с uid < 100). Но это тоже не полноценный вариант...

> Пользователь может сменить uid и gid, запустив чужое приложение.

Это каким образом? даже если файл с setuid флаг этого не будет.

> Как это сейчас делается - читается proc и уничтожаются все процессы, за
> исключением процессов, принадлежащих заданным пользователям

Тогда уж лучше действительно просто убить все процессы пользователя 'ПЭ',
для этого, кстати, и proc читать не надо.