Чому SIGUSR1 призводить до припинення процесу?

Мене здивував цей коментар в іншому запитанні:

Надсилання сигналу USR1 dd занадто рано після його запуску (тобто у баш-скрипті, рядок після його запуску) фактично припинить його

Хтось може пояснити, чому ?

signals

— Алоїз Магдал
джерело

Не стільки відповідь на ваше запитання, але спробуйте цей однокласник: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobsвідтворити описаний вами ефект.

— джиппі

Кожен сигнал має "диспозицію за замовчуванням" - що робить процес за замовчуванням, коли він отримує цей сигнал. На 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реєструє обробник, щоб перехопити сигнал і зробити щось корисне з ним, але якщо ви надто швидко подаєте сигнал, він ще не встиг зареєструвати цей обробник, тому замість цього відбувається дія за замовчуванням

— Михайло Мрозек
джерело

Я хотів би, щоб я міг двічі висловитись за те, що я усвідомлював цю незрозумілість. Побачивши, що процеси вмирають випадковим чином після видалення явного обробника сигналу, це заважає.

— DeaconDesperado

Чи є якийсь практичний спосіб контролювати цей стан гонки замість того, щоб просто спати протягом розумного часу (~ 0,5-1 сек)? (Я маю на увазі, поряд із чимось смішним, як захоплення та розбір straceрезультатів у сценарії оболонки…)

— Адріан Гюнтер

У мене був відмінний сценарій оболонки. Але раптом перестань працювати через те, що, ймовірно! Підпроцес, що надсилає kill -s SIGUSR1 $ PARENT_PID, стає надто швидким ?. Батько вважає, що батько припиняється нормально, але він все ще виконує цикл. Це гарна публікація. Я витрачав більшу частину дня, намагаючись зрозуміти це.

— Kemin Zhou