Почему SIGUSR1 вызывает завершение процесса?

20

Я был удивлен этим комментарием в другом вопросе:

Отправка dd сигнала USR1 слишком скоро после его запуска (т.е. в bash-скрипте, строка после того, как вы его запустили) фактически прервет его

Кто-нибудь может объяснить, почему ?

Алоис Махдал
источник
Не так много ответов на ваш вопрос, но попробуйте этот однострочный: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobsвоспроизвести эффект, который вы описываете.
Джиппи

Ответы:

38

Каждый сигнал имеет «расположение по умолчанию» - что процесс делает по умолчанию, когда получает этот сигнал. На signal(7)странице руководства есть таблица, в которой они перечислены:

Signal     Value     Action   Comment
──────────────────────────────────────────────────────────────────────
...
SIGUSR1   30,10,16    Term    User-defined signal 1
SIGUSR2   31,12,17    Term    User-defined signal 2

SIGUSR1и SIGUSR2оба имеют действие по умолчанию Term- процесс прекращается. ddрегистрирует обработчик для перехвата сигнала и делает с ним что-то полезное, но если вы подаете сигнал слишком быстро, у него еще не было времени зарегистрировать этот обработчик, поэтому вместо этого происходит действие по умолчанию

Михаил Мрозек
источник
1
Хотел бы я дважды проголосовать за то, что осознал эту безвестность. Видя, как процессы умирают случайно после удаления явного сигнала, обработчик сбивал с толку.
DeaconDesperado
1
Есть ли практический способ контролировать это состояние гонки вместо того, чтобы просто спать в течение разумного периода времени (~ 0,5-1 сек)? (Я имею в виду, помимо чего-то нелепого, например, захват и анализ straceвыходных данных в сценарии оболочки…)
Адриан Гюнтер,
У меня был сценарий оболочки работает нормально. Но внезапно перестану работать из-за вероятности! Подпроцесс, отправляющий kill -s SIGUSR1 $ PARENT_PID, теперь работает слишком быстро? Родительский родитель думает, что родительский процесс завершен нормально, но родитель все еще выполняет цикл. Это хорошая публикация. Я провел большую часть дня, пытаясь понять это.
Кемин Чжоу