Por que o SIGUSR1 faz com que o processo seja encerrado?

Fiquei surpreso com este comentário em outra pergunta:

Enviar dd o sinal USR1 muito cedo após o início (ou seja, em um script do bash, a linha depois de iniciada) de fato o encerrará

Alguém pode explicar o porquê ?

signals

— Alois Mahdal
fonte

Não é uma resposta à sua pergunta, mas tente esta frase: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobspara reproduzir o efeito que você está descrevendo.

— Jippie

Cada sinal tem uma "disposição padrão" - o que um processo faz por padrão quando recebe esse sinal. Há uma tabela na signal(7)página de manual listando-os:

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

SIGUSR1e SIGUSR2ambos têm a ação padrão Term- o processo é encerrado. ddregistra um manipulador para interceptar o sinal e fazer algo útil com ele, mas se você sinalizar muito rapidamente, ainda não teve tempo de registrar esse manipulador, portanto, a ação padrão ocorrerá

— Michael Mrozek
fonte

Eu gostaria de poder votar duas vezes por ter tomado consciência dessa obscuridade. Ver os processos morrerem aleatoriamente após a remoção de um manipulador de sinal explícito foi desconcertante.

— DeaconDesperado

Existe alguma maneira prática de controlar essa condição de corrida em vez de apenas dormir por um período de tempo razoável (~ 0,5-1 s)? (Quero dizer, ao lado de algo ridículo como capturar e analisar stracea saída em um shell script ...)

— Adrian Günter

Eu tinha um script de shell funcionando bem. Mas, de repente, pare de trabalhar por causa da provável !: Eu estava com o hyperthreding agora desligado. O subprocesso que envia kill -s SIGUSR1 $ PARENT_PID fica muito rápido agora? O pai principal acha que o pai é finalizado normalmente, mas o pai ainda está executando o loop. Esta é uma boa publicação. Passei a maior parte do dia tentando descobrir isso.

— Kemin Zhou #