Гарантированная остановка скрипта по ^C

pkill -9 <чтототам>

Можно даже несколько раз

так trap родительского процесса на то, как обрабатывается нажатие CTRL+C в том, что запускается в скрипте не влияет

Как 100% завершать скрипт и все его дочерние процессы

Посмотреть их pid-ы и сделать «kill -9 ...» :) . Умрут если не ждут завершения оперции ввода-вывода.

Ctrl-C - это SIGINT. Он перехватывается.

Есть eще Ctrl-\ - это SIGQUIT. Он тоже перехватывается, но реже.

Может подправить скрипт eix-sync ?

Посмотреть их pid-ы и сделать «kill -9 ...»

как это проще сделать через скрипт?

Может подправить скрипт eix-sync ?

что мне каждую программу подправлять?

Посмотреть их pid-ы и сделать «kill -9 ...» :) . Умрут если не ждут завершения оперции ввода-вывода.

это ты про uninterruptible sleep?

Делай свой обработчик сигналов в скрипте. Не дожидайся отклика от дочернего процесса, а отслеживай его завершение, либо прибивай.

что-то типа

kill -9 $(pgrep $0)

может сработать?

и навесить это дело на trap USR1 или что-то такое.

Зачем? $! - это pid дочернего процесса. И прежде, чем слать SIGKILL, я бы сначала заслал SIGTERM и подождал.

И не на USR1 бы вешал, а на EXIT.

как?

#!/bin/bash
set -m
trap "kill -9 \$(jobs -p) $$" 0 2 9 15
eix-sync
trap - 0

Да, можно попробовать убить дочерний, чтоб змоби не плодить. и вспомнил про $$:

тогда так:

kill $! || kill -9 $! || kill $$ || kill -9 $$ 

А на какой сигнал вешать - то уже дело десятое. Главное, что б не было обработки в дочернем (перехвата)

Надо сначала определиться, кто за собой не прибирается: скрипт или eix-sync. Ибо если eix-synс вызывается не в фоне, то SIGINT после ^C в него таки летит и это уже его ответственность прибить своих потомков. Скрипт тут ничего не поделает, т.к. не может узнать их pid-ы. А самого eix-sync хоть оббомбись kill-ами, это не поможет, наоборот, только хуже сделает, т.к. SIGKILL не даст ему за собой прибраться, даже если он и пытается.

Если нельзя чинить условно плохой eix-sync, то даже не зная pid-ов процессы можно попробовать поубивать на основании принадлежности к одной группе процессов (минус перед pid в команде kill), но тогда нужно обеспечить эту группу.

Можно попробовать так. Вроде, работает, но мне кажется там были какие-то подводные камни с этими группами процессов [кроме линуксоспецифичной команды setsid], которые я сейчас не могу вспомнить.

#!/bin/sh

if test -z "$OWNSID"; then
        export OWNSID=1
        exec setsid $0 "$@"
fi

trap 'kill -- -$$' TERM INT QUIT EXIT

for i in `seq 10`; do
        sleep 60 &
done

благодарю.
сейчас конструкция:

#!/bin/bash

[[ $OWNSID ]] ||{
  export OWNSID=1
  exec -- setsid -w -- "$@" "$@"
}

set -m

trap "kill -9 -- \$(jobs -p) -$$" 0 2 3 9 15

eix-sync

trap - 0 3

Плохого насоветовал. setsid форкается и скрипт уходит в фон и не получит уже SIGINT от терминала. Добавление опции -w эту ситуацию не улучшает. С ней setsid просто будет ждать завершения потомка, но, получив SIGINT, просто завершится сам, не перепослав сигнал потомку.

Но, похоже, bash сам всегда создаёт новую группу процессов, так что setsid делать не обязательно. Дополнительно нужно попросить шелл не создавать новые группы для каждой команды (по умолчанию в неинтерактивном режиме или set +m в интерактивном). Тогда по идее kill -$$ должен попасть во всё, что запущено из скрипта и не сбежало в отдельную группу.

Но в данном конкретном случае это всё равно не поможет, т.к. eix-sync это скрипт [а шелл сбегает в отдельную группу]. Увы.

неужели это никак нельзя реализовать?
может, какими-то обходными путями?

Контейнером.

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

Лично я так бы и сделал, потому что это самый простой метод, который будет работать для 97% всех скриптов.

Или, если все процессы, создаваемые скриптом можно отследить, то можно просто собирать $! в отдельную строку $local_pids, а на ^C разворачивать строку и убивать все запущенные процессы. Можно ещё написать функцию-инициализатор(допустим lp_init), которая будет все pid запускаемых процессов собирать в $local_pids - и запускать процессы так: lp_init eix; и функцию-киллер, которая будет проверять какие pid ещё работают, и вырубать именно их - и повесить её на ^С.

Это всё элементарно и понятно.

Но я тоже реквестирую способ объединить все создаваемые изнутри скрипта процессы без костылей(разве в линуксе можно вырваться из-под родительского процесса? если нет, то и проблемы тогда нет)

Можно ещё написать функцию-инициализатор(допустим lp_init), которая будет все pid запускаемых процессов собирать в $local_pids - и запускать процессы так: lp_init eix;

а как сделать чтоб функция собирала пиды? через & и $! ?

так не работает. переменная назначается после завершения программы

а, ну да, точно. вот так $@ &;

так работает как надо.
жаль только нельзя объединить команды в {} чтобы можно было

lp_init {
echo
eix-sync
...; }

Или, если все процессы, создаваемые скриптом можно отследить, то можно просто собирать $! в отдельную строку $local_pids, а на ^C разворачивать строку и убивать все запущенные процессы.

Этот список шелл сам ведёт. pid-ы запущенных им в фоне процессов выводит команда jobs -p. Проблема узнать pid-ы потомков потомков и далее по иерархии.

Этот список шелл сам ведёт. pid-ы запущенных им в фоне процессов выводит команда jobs -p.

но приведённый вариант работает, а до этого с set -m и jobs -p не работало.

Проблема узнать pid-ы потомков потомков и далее по иерархии.

как-то парсить /proc/ ?

но приведённый вариант работает, а до этого с set -m и jobs -p не работало.

Если речь про Гарантированная остановка скрипта по ^C (комментарий) , то там не работало потому что eix-sync запускался не в фоне. Соответственно вывод jobs -p был пустой. А set -m там вообще мимо кассы ;)

как-то парсить /proc/ ?

На мой вкус для скрипта это выглядит как слишком много возни.

там не работало потому что eix-sync запускался не в фоне

во магия. не знал

вывод jobs -p был пустой

дело оказалось не в jobs -p, а в минусе перед $$

А set -m там вообще мимо кассы

без него не работал бы jobs -p