Bash-скрипт dd и fsck не убит

Question

Мне нужно удалить lv, который используется в скрипте, который выполняет dd, fcsk и некоторые другие задачи на каком-то узле peer.so просто убивает скрипт и пытается удалить lv от этого однорангового узла, но, похоже, он не работает с ошибкой open lvs.

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

Answer 1

Если вы убьете свой скрипт, отправляющий SIGTERM или SIGKILL на свой PID, обычно вы отправляете сигнал только в родительский процесс. dd работает в дочернем процессе, который не получит сигнал. Как только родитель убит, дочерний объект наследуется init, и он будет продолжать работать.

Для передачи сигнала с использованием всей группы процессов:

kill -- -PID 

или

kill -9 -PID 

где PID является PID вашего сценария. Обратите внимание на знак минус, добавленный к PID. От man kill

-n  where n is larger than 1. All processes in process group n are signaled. 

Пример

Я бегу дд из сценария оболочки:

PID TGID TID PGID PPID COMMAND 
5828 5828 5828 5828 20127 sh 
5829 5829 5829 5828 5828 dd 

Процесс Идентификатор группы (PGID) является PID-родителя (5828).

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

kill -9 5828 

я получаю следующую ситуацию:

PID TGID TID PGID PPID COMMAND 
5829 5829 5829 5828  1 dd 

дд еще работает, и он был унаследован инициализации (PPID является 1). Если вместо этого я бегу:

kill -9 -5828 

как сценарий и дд убивают.

EDIT: Процесс, который вы хотите убить, запускается удаленно через ssh.

После запуска ssh dd/fsck удаленно меняет все. Простым, но не рекомендованным решением может быть следующее.

Сценарий запускает dd/fsck удаленно через ssh в фоновом режиме и получает PID.

remote_pid=$(ssh user@host 'dd if=/dev/urandom of=/dev/zero & echo $!') 

Затем сценарий не должен возвращаться и улавливать ваш сигнал. Ваш обработчик открывает новое ssh-соединение и сигнализирует remote_pid.

Очистка во втором подключении ssh не рекомендуется, так как это может привести к сбою и оставить много беспорядка.

Для более продвинутого решения см https://unix.stackexchange.com/questions/40023/get-ssh-to-forward-signals