Trong trường hợp nào SIGHUP không được gửi đến một công việc khi bạn đăng xuất?


10

Tôi đã đọc một câu trả lời từ một người dùng đã tuyên bố rằng đang chạy

foo 2>&1 >& output.log &

sẽ dẫn đến việc footiếp tục chạy ngay cả khi họ đăng xuất. Theo người dùng này, điều này thậm chí còn hoạt động trên các kết nối SSH.

Tôi thực sự không tin rằng, vì tôi có ấn tượng rằng trong trường hợp ngắt kết nối với SSH, hoặc chấm dứt TTY, trình bao và do đó các quy trình của nó sẽ nhận được SIGHUP, khiến chúng chấm dứt. Điều này, theo giả định của tôi, là lý do duy nhất để sử dụng nohuptrong những trường hợp như vậy, hoặc tmux, screenet al.

Sau đó tôi nhìn vào hướng dẫn của glibc :

Tín hiệu này cũng được sử dụng để báo cáo chấm dứt quá trình kiểm soát trên thiết bị đầu cuối với các công việc liên quan đến phiên đó; chấm dứt này có hiệu quả ngắt kết nối tất cả các quy trình trong phiên từ thiết bị đầu cuối kiểm soát.

Điều này dường như để xác nhận suy nghĩ của tôi. Nhưng nhìn xa hơn, nó nói :

Nếu quy trình là một nhà lãnh đạo phiên có thiết bị đầu cuối kiểm soát, thì tín hiệu SIGHUP được gửi đến từng quy trình trong công việc nền trước và thiết bị đầu cuối kiểm soát bị tách khỏi phiên đó.

Vì vậy, điều này có nghĩa là các công việc được đặt trong nền sẽ không nhận được SIGHUP?

Để tôi thêm bối rối, tôi đã chạy một phiên Zsh tương tác, chạy yes >& /dev/null &và gõ exit, khi Zsh cảnh báo tôi rằng tôi đã chạy việc và sau khi gõ exitlần thứ hai, nói với tôi rằng nó đã SIGHUPed một công việc. Làm chính xác như vậy trong Bash để lại công việc đang chạy


Trước đây tôi đã gặp sự cố với một máy chủ đột nhiên bị ngắt kết nối qua ssh và quá trình của tôi chỉ tiếp tục chạy nhưng không có bất kỳ liên quan nào, vì vậy tôi phải đăng nhập lại và gửi SIGHUP / TERM / KILL để kết thúc chúng. Vì vậy, theo cùng một logic, tôi đã thử nghiệm ngay bây giờ, gõ logoutyesvẫn đang chạy.
Braiam

Ngoài việc có gửi SIGHUP hay không, liệu một quy trình đã xác định trình xử lý tín hiệu (và bắt SIGHUP) hay mặt nạ tín hiệu là các yếu tố bổ sung trong việc liệu nó có bị chấm dứt khi gửi tín hiệu đó hay không. Vì vậy, chỉ vì nó vẫn chạy sau khi đăng xuất không có nghĩa là nó không được gửi tín hiệu đó
Tim B

Bạn đang đề cập đến câu hỏi này: serverfault.com/questions/115999/ trên ? Câu trả lời dường như được tìm thấy ở đó - đó là RedHat không đặt shopt theo mặc định. Đó là cách giải quyết cấu hình cụ thể của RedHat.
Boris Burkov

@Bob Không, tôi chưa từng thấy cái này trước đây, nhưng nó là một tài nguyên tốt. Cảm ơn!
slhck

Vui vì nó đã giúp. Thật ra Raphael cũng đang đề cập đến vấn đề đó.
Boris Burkov

Câu trả lời:


18

Bash dường như chỉ gửi SIGHUPnếu nó tự nhận a SIGHUP, ví dụ như xảy ra khi thiết bị đầu cuối ảo bị đóng hoặc khi kết nối SSH bị gián đoạn. Từ tài liệu :

Shell thoát theo mặc định khi nhận được SIGHUP. Trước khi thoát, một vỏ tương tác gửi lại SIGHUP cho tất cả các công việc, đang chạy hoặc dừng. Các công việc đã dừng được gửi SIGCONT để đảm bảo rằng họ nhận được SIGHUP. Để ngăn vỏ gửi tín hiệu SIGHUP đến một công việc cụ thể, nó phải được xóa khỏi bảng công việc với phần dựng sẵn (xem phần Điều khiển công việc) hoặc được đánh dấu để không nhận SIGHUP bằng cách sử dụng từ chối -h.

Vì vậy, nếu bạn gõ exithoặc nhấn Ctrl+ Dtất cả quá trình nền sẽ vẫn còn, vì điều này không gửi tín hiệu gác máy đến Bash.

Bạn có thể buộc Bash cảnh báo bạn về thực tế là vẫn đang chạy các quy trình nền với

shopt -s checkjobs

Có một tùy chọn để gửi SIGHUPlối thoát nếu bạn đang ở trong một vỏ tương tác ( xem tại đây ). Nhưng nó không hoạt động trên máy của tôi với Bash 4.2.25. Có lẽ nó làm việc cho bạn

shopt -s huponexit

Vì vậy, khi một kết nối SSH bị gián đoạn, SIGHUPđược gửi, nếu không, với một lối thoát sạch, công việc tiếp tục chạy? Điều đó giải thích những gì tôi thấy.
slhck

Đúng. Tín hiệu gác máy chỉ có ở trường hợp đặc biệt, khi kết nối với người dùng bị gián đoạn.
Raphael Ahrens



@npostavs cảm ơn vì thông tin tôi đã thêm nó vào câu trả lời.
Raphael Ahren
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.