Tại sao SIGUSR1 khiến quá trình bị chấm dứt?

Tôi đã ngạc nhiên với nhận xét này trong câu hỏi khác:

Gửi dd tín hiệu USR1 quá sớm sau khi nó bắt đầu (nghĩa là trong tập lệnh bash, dòng sau khi bạn khởi động nó) thực tế sẽ chấm dứt nó

Ai có thể giải thích tại sao ?

signals

— Alois Mahdal
nguồn

Không có nhiều câu trả lời cho câu hỏi của bạn, nhưng hãy thử bài viết này: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobsđể tái tạo hiệu ứng bạn đang mô tả.

— jippie

Mỗi tín hiệu có một "bố trí mặc định" - mặc định một quá trình thực hiện khi nhận được tín hiệu đó. Có một bảng trong signal(7)trang người đàn ông liệt kê chúng:

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

SIGUSR1và SIGUSR2cả hai đều có hành động mặc định Term- quá trình kết thúc. ddđăng ký một trình xử lý để chặn tín hiệu và làm điều gì đó hữu ích với nó, nhưng nếu bạn báo hiệu quá nhanh thì vẫn chưa có thời gian để đăng ký trình xử lý đó, vì vậy hành động mặc định sẽ xảy ra

— Michael Mrozek
nguồn

Tôi ước tôi có thể nâng cao hai lần vì đã nhận thức được sự tối nghĩa này. Nhìn thấy các quá trình chết ngẫu nhiên sau khi loại bỏ một trình xử lý tín hiệu rõ ràng là không hài lòng.

— DeaconDesperado

Có cách nào thực tế để kiểm soát tình trạng cuộc đua này thay vì chỉ ngủ trong một khoảng thời gian hợp lý (~ 0,5-1 giây) không? (Ý tôi là, bên cạnh một thứ gì đó lố bịch như bắt và phân tích cú pháp straceđầu ra trong tập lệnh shell)

— Adrian Günter

Tôi đã có một kịch bản shell hoạt động tốt. Nhưng đột nhiên ngừng hoạt động vì có khả năng!: Tôi đã bị cường điệu ngay bây giờ. Quá trình gửi gửi kill -s SIGUSR1 $ PARENT_PID bây giờ có quá nhanh không?. Cha mẹ lớn nghĩ rằng cha mẹ bị chấm dứt bình thường, nhưng cha mẹ vẫn đang thực hiện vòng lặp. Đây là một bài viết tốt. Tôi đã dành phần lớn thời gian trong ngày để cố gắng tìm ra điều này.

— Kemin Zhou