Mengapa SIGUSR1 menyebabkan proses dihentikan?

Saya terkejut dengan komentar ini dalam pertanyaan lain:

Mengirimkan dd sinyal USR1 terlalu cepat setelah dimulai (yaitu dalam skrip bash, baris setelah Anda memulainya) sebenarnya akan menghentikannya

Adakah yang bisa menjelaskan mengapa ?

signals

— Alois Mahdal
sumber

Bukan jawaban untuk pertanyaan Anda, tapi coba ini satu-baris: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobsuntuk mereproduksi efek yang Anda gambarkan.

— jippie

Setiap sinyal memiliki "disposisi default" - proses apa yang dilakukan secara default ketika menerima sinyal itu. Ada tabel di signal(7)halaman manual yang mencantumkannya:

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

SIGUSR1dan SIGUSR2keduanya memiliki tindakan default Term- proses dihentikan. ddmendaftarkan handler untuk mencegat sinyal dan melakukan sesuatu yang berguna dengannya, tetapi jika Anda memberi sinyal terlalu cepat, ia belum punya waktu untuk mendaftarkan handler itu, jadi tindakan default yang terjadi malah

— Michael Mrozek
sumber

Saya berharap saya dapat membenarkan dua kali karena dibuat sadar akan ketidakjelasan ini. Melihat proses mati secara acak setelah melepaskan penangan sinyal eksplisit membingungkan.

— DeaconDesperado

Apakah ada cara praktis untuk mengontrol kondisi balapan ini daripada hanya tidur dalam waktu yang wajar (~ 0,5-1 detik)? (Maksudku, di samping sesuatu yang menggelikan seperti menangkap dan mengurai straceoutput dalam skrip shell ...)

— Adrian Günter

Saya memiliki skrip shell yang berfungsi dengan baik. Tapi tiba-tiba berhenti bekerja karena kemungkinan !: Saya mengalami hipertensi sekarang. Subproses yang mengirimkan kill -s SIGUSR1 $ PARENT_PID menjadi terlalu cepat sekarang ?. Orang tua utama berpikir bahwa orang tua diakhiri secara normal, tetapi orang tua masih menjalankan loop. Ini adalah posting yang bagus. Saya telah menghabiskan sebagian besar hari berusaha mencari tahu hal ini.

— Kemin Zhou