SIGUSR1 neden işlemin sonlandırılmasına neden oluyor?

Başka bir soruda bu yorum ile şaşırdım :

USR1 sinyalini başladıktan hemen sonra (yani bir bash betiğinde, başlattıktan sonraki satır) göndermek aslında onu sonlandıracaktır.

Nedenini açıklayan var mı?

signals

— Alois Mahdal
kaynak

Sorunuza çok fazla cevap yok, ama şu tek astarı deneyin: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobstarif ettiğiniz efekti yeniden üretmek için.

— jippie

Her sinyalin bir "varsayılan düzen" vardır - bir işlem bu sinyali aldığında varsayılan olarak ne yapar? signal(7)Man sayfasında onları listeleyen bir tablo var :

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

SIGUSR1ve SIGUSR2her ikisinin de varsayılan eylemi vardır Term- işlem sonlandırılır. ddsinyali yakalamak ve onunla faydalı bir şey yapmak için bir işleyiciyi kaydeder, ancak çok hızlı sinyal verirseniz, bu işleyiciyi kaydetmek için henüz zamanı olmamıştır, bu nedenle varsayılan eylem gerçekleşir

— Michael Mrozek
kaynak

Keşke bu belirsizliğin farkında olmak için iki kez vekalet edebilseydim. Görme işlemleri, açık bir sinyal işleyicinin çıkarılmasından sonra rasgele ölüyordu.

— DeaconDesperado

Makul bir süre uyumak yerine bu yarış durumunu kontrol etmenin pratik bir yolu var mı (~ 0.5-1 sn)? (Yani, stracebir kabuk betiğinde çıktı yakalama ve ayrıştırma gibi gülünç bir şeyin yanında …)

— Adrian Günter

İyi çalışan bir kabuk komut dosyası vardı. Ama aniden büyük olasılıkla çalışmayı durdurun !: Şimdi hiper-taramam vardı. Kill -s SIGUSR1 $ PARENT_PID gönderen alt işlem artık çok mu hızlı? Büyük ebeveyn, ebeveynin normal olarak sonlandırıldığını düşünür, ancak ebeveyn hala döngüyü yürütmektedir. Bu iyi bir gönderi. Günün çoğunu anlamaya çalışıyorum.

— Kemin Zhou