Tại sao, su su su -c <lệnh> & dường như cho phép một lệnh chạy trong nền mà không bị treo

Tôi đã giúp một đồng nghiệp đang gặp vấn đề với quá trình làm nền liên tục chết.

Tôi phát hiện ra rằng họ đang bắt đầu quá trình nền bằng cách đăng nhập vào máy chủ và thực thi:

su - <user> -c '<command>' &

"Aha", tôi kêu lên. "Nếu bạn bắt đầu một lệnh với" & "nó sẽ bị treo khi bạn thoát khỏi thiết bị đầu cuối điều khiển. Bạn cần sử dụng một cái gì đó như nohup để đạt được điều này. Thực sự quá trình này cần hỗ trợ chạy như một daemon, tut tut."

Chúng tôi đã thử nghiệm lệnh trên để chứng minh quan điểm của tôi và ... nó dường như hoạt động: quá trình bắt đầu bằng lệnh không thoát khi chúng tôi thoát khỏi thiết bị đầu cuối chạy lệnh trên.

lệnh là một tập lệnh Python tùy chỉnh có đầu ra đi đến một tệp. Theo như tôi có thể nói, không có khả năng "daemonize" thông minh nào trong kịch bản. Nó không thực hiện bất kỳ điều gì cần thiết để chạy như một daemon được liệt kê trong Wikipedia: Daemon (tính toán): Trang tạo .

Chạy lệnh như vậy hành xử như mong đợi:

<command> &
exit

Trong trường hợp trên, quá trình nền bắt đầu bằng lệnh thoát khi chúng ta thoát khỏi thiết bị đầu cuối.

Câu hỏi của tôi là:

1. Điều gì đang xảy ra khi chúng ta thêm "su - -c &" ngăn quá trình thoát khi thiết bị đầu cuối của chúng ta thoát. Tôi muốn hiểu chi tiết về thiết bị đầu cuối điều khiển, đầu vào và đầu ra tiêu chuẩn, v.v.

2. Đây có phải là một cách hợp lý để đạt được mục tiêu chạy lệnh này như là một quá trình nền. Nếu không, tai sao không?

Tôi muốn tuyên truyền các thực tiễn tốt nhất trong công ty của mình, nhưng tôi cần có khả năng chứng minh và sao lưu mọi khuyến nghị tôi đưa ra.

Tôi cũng muốn hiểu chính xác những gì đang diễn ra.

Có một số cách mà một quá trình có thể bị giết vì một thiết bị đầu cuối sắp chết.

1. Cách đầu tiên là trình điều khiển đầu cuối trong kernel gửi tín hiệu SIGHUP đến quá trình điều khiển mà đầu cuối là đầu cuối điều khiển . Trong hầu hết các trường hợp, quá trình kiểm soát là lớp vỏ ban đầu được bắt đầu trong thiết bị đầu cuối và thiết bị đầu cuối kiểm soát của nó là lớp mà stdin, stdout và stderr của nó được kết nối. Một quá trình sẽ bị ngắt kết nối khỏi thiết bị đầu cuối kiểm soát nếu nó gọi setsid.

2. Cách thứ hai là shell, khi nhận được SIGHUP, sẽ gửi lại tín hiệu đó đến các quy trình con của nó - chính xác hơn là các công việc nền của nó. Một số shell (ksh, bash, zsh) có disownsẵn nội dung để báo cho shell không gửi SIGHUP cho một công việc cụ thể.

3. Nếu thiết bị đầu cuối biến mất và một chương trình cố gắng đọc từ nó, nó sẽ được thông báo về tình trạng cuối tập tin (hoặc có thể là EIO cho một công việc nền). Nếu thiết bị đầu cuối biến mất và một chương trình cố gắng ghi vào nó, ghi sẽ trả về với lỗi EIO. Những thứ này có thể khiến chương trình thoát ra.

Vì vậy, điều suthay đổi ở đây là (2) thường sẽ khiến lớp vỏ ban đầu giết chết công việc nền, nhưng vì quá trình nền đó đang chạy như một người dùng khác, tín hiệu không thể được gửi và quá trình nền vẫn tiếp tục.