Perché SIGUSR1 causa l'interruzione del processo?

Sono stato sorpreso da questo commento in un'altra domanda:

L'invio del segnale USR1 troppo presto dopo l'avvio (ovvero in uno script bash, la riga dopo averlo avviato) lo interromperà di fatto

Qualcuno può spiegare perché ?

signals

— Alois Mahdal
fonte

Non tanto una risposta alla tua domanda, ma prova questo one-liner: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobsper riprodurre l'effetto che stai descrivendo.

— jippie,

Ogni segnale ha una "disposizione di default" - cosa fa un processo di default quando riceve quel segnale. C'è una tabella nella signal(7)pagina man che li elenca:

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

SIGUSR1ed SIGUSR2entrambi hanno l'azione predefinita Term: il processo è terminato. ddregistra un gestore per intercettare il segnale e fare qualcosa di utile con esso, ma se segnali troppo rapidamente non ha ancora avuto il tempo di registrare quel gestore, quindi si verifica invece l'azione predefinita

— Michael Mrozek
fonte

Vorrei poter votare due volte per essermi reso conto di questa oscurità. Vedere i processi morire in modo casuale dopo aver rimosso un gestore di segnale esplicito è stato sconcertante.

— DeaconDesperado

Esiste un modo pratico per controllare questa condizione di gara invece di dormire solo per un ragionevole lasso di tempo (~ 0,5-1 sec)? (Voglio dire, a parte qualcosa di ridicolo come catturare e analizzare l' straceoutput in uno script di shell ...)

— Adrian Günter,

Ho fatto funzionare bene uno script di shell. Ma improvvisamente smetti di funzionare a causa del probabile !: Ho avuto hyperthreding ora spento. Il sottoprocesso che invia kill -s SIGUSR1 $ PARENT_PID diventa troppo veloce ora ?. Il nonno pensa che il genitore sia terminato normalmente, ma il genitore sta ancora eseguendo il ciclo. Questa è una buona pubblicazione. Ho trascorso gran parte della giornata a cercare di capirlo.

— Kemin Zhou,