ทำไม SIGUSR1 ทำให้กระบวนการถูกยกเลิก?

ฉันรู้สึกประหลาดใจกับความคิดเห็นนี้ในคำถามอื่น:

การส่งสัญญาณ USR1 ในไม่ช้าหลังจากเริ่มต้น (เช่นในสคริปต์ทุบตีบรรทัดหลังจากที่คุณเริ่มต้น) จะเป็นการยกเลิกสัญญาณ

ใครสามารถอธิบายได้ว่าทำไม ?

signals

ไม่ใช่คำตอบสำหรับคำถามของคุณมากนัก แต่ลองใช้หนึ่งบรรทัด{ dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobsต่อไปนี้เพื่อสร้างเอฟเฟกต์ที่คุณกำลังอธิบาย

— jippie

แต่ละสัญญาณมี "การจัดการเริ่มต้น" - กระบวนการจะทำตามค่าเริ่มต้นเมื่อได้รับสัญญาณนั้น มีตารางใน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ลงทะเบียนตัวจัดการเพื่อสกัดสัญญาณและทำสิ่งที่มีประโยชน์กับมัน แต่ถ้าคุณส่งสัญญาณเร็วเกินไปก็ไม่มีเวลาลงทะเบียนตัวจัดการนั้นดังนั้นการกระทำเริ่มต้นจึงเกิดขึ้นแทน

— Michael Mrozek
แหล่งที่มา

ฉันหวังว่าฉันจะโหวตได้สองครั้งเพราะตระหนักถึงความสับสนนี้ การเห็นกระบวนการตายแบบสุ่มหลังจากลบตัวจัดการสัญญาณที่ชัดเจนกำลังทำให้เกิดความสับสน

— DeaconDesperado

มีวิธีใดที่ใช้ประโยชน์ได้ในการควบคุมสภาพการแข่งขันนี้แทนที่จะเพียงแค่นอนในระยะเวลาที่เหมาะสม (ประมาณ 0.5-1 วินาที)? (ฉันหมายถึงข้างสิ่งที่น่าหัวเราะเหมือนการจับภาพและการแยกวิเคราะห์straceในเชลล์สคริปต์…)

— Adrian Günter

ฉันมีเชลล์สคริปต์ทำงานได้ดี แต่ทันใดนั้นก็หยุดทำงานเพราะมีโอกาส!: ตอนนี้ฉันเลิกกิจการหลายอย่างแล้ว กระบวนการย่อยที่ส่ง kill -s SIGUSR1 $ PARENT_PID เร็วเกินไปไหม ผู้ปกครองที่ยิ่งใหญ่คิดว่าผู้ปกครองถูกยกเลิกตามปกติ แต่ผู้ปกครองยังคงดำเนินการลูป นี่คือการโพสต์ที่ดี ฉันใช้เวลาส่วนใหญ่ไปกับการพยายามคิดออก

— Kemin Zhou