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

[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
    ....
Источник

2 ответа

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

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

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

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

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

Источник

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

Если вы хотите убить свой бег 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 и он все еще распечатывает отчет.

Источник
Другие вопросы по тегам