Почему сигнал SIGTERM не работает для группы процессов?

Question

[EDIT] Я изменил SIGINT на SIGTERM в целом вопрос.

У меня есть скрипт, который запускает скрипт подпроцесса, который запускает jboss.

#!/bin/sh
....
start_jboss.sh &
trap 'kill -SIGTERM 0' EXIT HUP TERM INT
....

Я хочу отправить сигнал SIGTERM в jboss, когда мой скрипт был убит, прерван или прерван. Но приведенный выше код не заканчивается JBoss. Сигнал KILL убивает JBoss (следующий код), но JBoss не снимает блокировку базы данных H2. В моем случае важно снять блокировку H2, поэтому я должен использовать сигнал SIGTERM.

#!/bin/sh
....
start_jboss.sh &
trap 'kill -9 0' EXIT HUP TERM INT
....

Мой JBoss использует порт 8080, поэтому следующая команда дает мне pid JBoss:

sudo netstat -lnpt | grep 8080

Если я выполню следующую команду:

 kill -SIGTERM jboss_pid_from_netstat_command

затем JBoss прерывается и снимает блокировку базы данных H2.

Как изменить мое действие ловушки, чтобы отправить SIGTERM в JBoss? Я не знаю, почему SIGKILL работает, а SIGTERM не работает.

[EDIT] Я изменил SIGINT на SIGTERM в целом вопрос.

РЕДАКТИРОВАТЬ

Сценарий запуска JBoss (standalone.sh) запускает JBoss в процессе переднего плана, если LAUNCH_JBOSS_IN_BACKGROUND не установлен, и запускает JBoss в фоновом процессе, если установлена эта переменная. Поэтому я установил эту переменную в своем скрипте. Следующие сценарии работают правильно тогда:

#!/bin/sh
....
export LAUNCH_JBOSS_IN_BACKGORUND=a
standalone.sh &
trap 'kill -SIGTERM 0' EXIT HUP TERM INT
....


#!/bin/sh
....
export LAUNCH_JBOSS_IN_BACKGORUND=a
standalone.sh &
trap 'kill -SIGTERM $(jobs -pr)' EXIT HUP TERM INT
....


#!/bin/sh
....
export LAUNCH_JBOSS_IN_BACKGORUND=a
standalone.sh &
jboss_script_id=$!
trap 'kill -SIGTERM $jboss_script_id' EXIT HUP TERM INT
....

Я до сих пор не знаю, почему следующий код не работает. Я работаю на Centos с Bash. Я проверил его на Ubuntu с дефисом, и следующие коды работают, но выдается предупреждение о core dump .

(не работа)

#!/bin/sh
....
standalone.sh &
trap 'kill -SIGTERM 0' EXIT HUP TERM INT
....

или (не работает)

#!/bin/sh
....
standalone.sh &
trap 'kill -SIGTERM $(jobs -pr)' EXIT HUP TERM INT
....

или (не работает)

#!/bin/sh
    ....
    standalone.sh &
    jboss_script_id=$!
    trap 'kill -SIGTERM $jboss_script_id' EXIT HUP TERM INT
    ....

Answer 1

Вероятно, что сервер jboss имеет обработчик завершения в том случае, если он был прерван во время обработки ввода-вывода (например, при записи в базу данных). Сигналы TERM и INT могут обрабатываться, чтобы гарантировать, что база данных не будет повреждена при поступлении сигнала и процесс занят выполнением операций ввода-вывода.

С SIGKILL нет благодати - процесс выполняется безжалостно, независимо от того, что он делает. Для сигнала SIGKILL не разрешен обработчик. Это может быть важной причиной, чтобы избежать kill -9 для завершения процесса, если нет альтернативы.

По какой-то причине уничтожение всей группы процессов мешает корректному завершению и снятию блокировки базы данных. Попробуйте убить сервер jboss следующим образом. ПРИМЕЧАНИЕ. Возможно, вам потребуется расширить команду kill, чтобы убедиться, что все дочерние элементы сценария также умерли (я не знаю весь ваш сценарий).

trap 'kill -SIGTERM $(jobs -pr)' EXIT HUP TERM INT

Что убьет jboss, так как команда jobs вернет фоновые процессы, запущенные из оболочки (т. Е. Процесс jboss в вашем случае).

Answer 2

Я была такая же проблема.

Если вы хотите убить ваш запущенный процесс valgrind , Ctrl+C не сделает этого.

Поскольку valgrind обрабатывает некоторые сигналы, мы можем послать ему сигнал, чтобы он мог что-то сделать. Если вы не знаете список сигналов, вы можете проверить его, сказав (на терминале):

your_user_name:Directory$ kill -l

Эта команда выведет список всех доступных для вас сигналов.

1. Запустите вашу программу с помощью valgrind (Пример: valgrind --tool=memcheck ./prog)

2. Проверьте Valgrind PID на левой стороне. Пример: == 938 == Memcheck, детектор ошибок памяти

3. Откройте другое окно терминала: kill -SIGTRAP 938

Это должно работать для вас.

Если это не работает для вас, вы можете попробовать отправить другие сигналы, и я уверен, что вы найдете тот, который прерывает valgrind и он все еще печатает отчет.