Lý do để thực hiện một ngã ba đôi khi tạo ra một daemon là gì?

Tôi đang cố gắng tạo ra một daemon trong python. Tôi đã tìm thấy câu hỏi sau đây , trong đó có một số tài nguyên tốt trong đó tôi hiện đang theo dõi, nhưng tôi tò mò về lý do tại sao một ngã ba đôi là cần thiết. Tôi đã tìm hiểu trên google và tìm thấy nhiều tài nguyên tuyên bố rằng một tài nguyên là cần thiết, nhưng không phải tại sao.

Một số đề cập rằng đó là để ngăn daemon có được một thiết bị đầu cuối kiểm soát. Làm thế nào nó sẽ làm điều này mà không có ngã ba thứ hai? Những hậu quả là gì?

Nhìn vào mã được tham chiếu trong câu hỏi, lời biện minh là:

Ngã ba một đứa trẻ thứ hai và thoát ra ngay lập tức để ngăn chặn zombie. Điều này làm cho quá trình con thứ hai bị mồ côi, làm cho quá trình init chịu trách nhiệm dọn dẹp nó. Và, vì đứa trẻ đầu tiên là một nhà lãnh đạo phiên không có thiết bị đầu cuối kiểm soát, nó có thể có được nó bằng cách mở một thiết bị đầu cuối trong tương lai (hệ thống dựa trên Hệ thống V). Cái ngã ba thứ hai này đảm bảo rằng đứa trẻ không còn là người dẫn đầu phiên, ngăn không cho daemon có được một thiết bị đầu cuối kiểm soát.

Vì vậy, đó là để đảm bảo rằng daemon được cấp lại cho init (chỉ trong trường hợp quá trình khởi động daemon tồn tại lâu) và loại bỏ bất kỳ cơ hội nào của daemon lấy lại tty kiểm soát. Vì vậy, nếu cả hai trường hợp này không áp dụng, thì một ngã ba là đủ. " Lập trình mạng Unix - Stevens " có một phần hay về vấn đề này.

Tôi đã cố gắng để hiểu về ngã ba đôi và vấp phải câu hỏi này ở đây. Sau rất nhiều nghiên cứu, đây là những gì tôi tìm ra. Hy vọng nó sẽ giúp làm rõ mọi thứ tốt hơn cho bất cứ ai có cùng câu hỏi.

Trong Unix, mọi tiến trình thuộc về một nhóm, lần lượt thuộc về một phiên. Đây là hệ thống phân cấp

Phiên (SID) → Nhóm quy trình (PGID) → Quy trình (PID)

Quá trình đầu tiên trong nhóm quy trình trở thành người lãnh đạo nhóm quy trình và quy trình đầu tiên trong phiên trở thành người lãnh đạo phiên. Mỗi phiên có thể có một TTY liên kết với nó. Chỉ người lãnh đạo phiên có thể kiểm soát TTY. Để một quá trình thực sự được trình bày (chạy trong nền), chúng ta nên đảm bảo rằng người lãnh đạo phiên bị giết để không có khả năng phiên nào chiếm quyền kiểm soát TTY.

Tôi đã chạy chương trình daemon ví dụ python của Sander Marechal từ trang web này trên Ubuntu của tôi. Dưới đây là kết quả với ý kiến ​​của tôi.

1. `Parent`    = PID: 28084, PGID: 28084, SID: 28046
2. `Fork#1`    = PID: 28085, PGID: 28084, SID: 28046
3. `Decouple#1`= PID: 28085, PGID: 28085, SID: 28085
4. `Fork#2`    = PID: 28086, PGID: 28085, SID: 28085

Lưu ý rằng quy trình là người dẫn đầu phiên sau Decouple#1, bởi vì đó là PID = SID. Nó vẫn có thể kiểm soát một TTY.

Lưu ý rằng Fork#2không còn là người lãnh đạo phiên PID != SID. Quá trình này không bao giờ có thể kiểm soát một TTY. Quả thật daemon.

Cá nhân tôi thấy thuật ngữ ngã ba lần là khó hiểu. Một thành ngữ tốt hơn có thể là fork-decouple-fork.

Liên kết quan tâm bổ sung:

• Các quy trình Unix - http://www.win.tue.nl/~aeb/linux/lk/lk-10.html

Nói một cách chính xác, nĩa đôi không liên quan gì đến việc nuôi dạy lại con daemon khi còn nhỏ init. Tất cả những gì cần thiết để nuôi dạy lại đứa trẻ là cha mẹ phải thoát ra. Điều này có thể được thực hiện chỉ với một ngã ba duy nhất. Ngoài ra, thực hiện một ngã ba đôi tự nó không tái định nghĩa quá trình trình nền init; cha của daemon phải thoát ra. Nói cách khác, cha mẹ luôn thoát ra khi tạo một daemon thích hợp để quá trình daemon được phát hiện lại init.

Vậy tại sao ngã ba đôi? POSIX.1-2008 Mục 11.1.3, " Thiết bị đầu cuối kiểm soát ", có câu trả lời (nhấn mạnh thêm):

Thiết bị đầu cuối kiểm soát cho một phiên được phân bổ bởi người lãnh đạo phiên theo cách xác định thực hiện. Nếu một nhà lãnh đạo phiên không có thiết bị đầu cuối kiểm soát và mở tệp thiết bị đầu cuối chưa được liên kết với phiên mà không sử dụng O_NOCTTYtùy chọn (xem open()), thì nó được xác định theo thực thi liệu thiết bị đầu cuối có trở thành thiết bị đầu cuối kiểm soát của nhà lãnh đạo phiên hay không. Nếu một quá trình đó là không một nhà lãnh đạo phiên mở một tập tin thiết bị đầu cuối, hoặc các O_NOCTTYtùy chọn được sử dụng trên open(), sau đó thiết bị đầu cuối sẽ không trở thành thiết bị đầu cuối kiểm soát của quá trình gọi .

Điều này cho chúng ta biết rằng nếu một quy trình daemon làm điều gì đó như thế này ...

int fd = open("/dev/console", O_RDWR);

... Sau đó, quy trình trình nền có thể có được /dev/consolenhư là thiết bị đầu cuối kiểm soát của nó, tùy thuộc vào việc quy trình trình nền có phải là người dẫn đầu phiên hay không và tùy thuộc vào việc triển khai hệ thống. Chương trình có thể đảm bảo rằng cuộc gọi trên sẽ không có được thiết bị đầu cuối kiểm soát nếu trước tiên chương trình đảm bảo rằng đó không phải là người dẫn đầu phiên.

Thông thường, khi khởi chạy một daemon, setsidđược gọi (từ tiến trình con sau khi gọi fork) để phân tách daemon khỏi thiết bị đầu cuối kiểm soát của nó. Tuy nhiên, gọi setsidcũng có nghĩa là quá trình gọi sẽ là người lãnh đạo phiên của phiên mới, điều này mở ra khả năng daemon có thể yêu cầu thiết bị đầu cuối kiểm soát. Kỹ thuật fork đôi đảm bảo rằng quy trình daemon không phải là người dẫn đầu phiên, sau đó đảm bảo rằng một cuộc gọi đến open, như trong ví dụ trên, sẽ không dẫn đến quá trình daemon lấy lại thiết bị đầu cuối điều khiển.

Kỹ thuật double-fork là một chút hoang tưởng. Có thể không cần thiết nếu bạn biết rằng trình nền sẽ không bao giờ mở tệp thiết bị đầu cuối. Ngoài ra, trên một số hệ thống, có thể không cần thiết ngay cả khi daemon mở tệp thiết bị đầu cuối, vì hành vi đó được xác định theo thực thi. Tuy nhiên, một điều không được xác định theo triển khai là chỉ có người lãnh đạo phiên có thể phân bổ thiết bị đầu cuối kiểm soát. Nếu một quá trình không phải là một nhà lãnh đạo phiên, nó không thể phân bổ một thiết bị đầu cuối kiểm soát. Do đó, nếu bạn muốn bị hoang tưởng và chắc chắn rằng quy trình daemon không thể vô tình có được một thiết bị đầu cuối kiểm soát, bất kể mọi chi tiết cụ thể do triển khai thực hiện, thì kỹ thuật hai ngã ba là rất cần thiết.

Lấy từ CTK xấu :

"Trên một số hương vị của Unix, bạn buộc phải thực hiện một cú đúp khi khởi động, để chuyển sang chế độ daemon. Điều này là do việc tách đơn không được đảm bảo tách khỏi thiết bị đầu cuối điều khiển."

Theo "Lập trình nâng cao trong môi trường Unix", bởi Stephens và Rago, ngã ba thứ hai là một khuyến nghị và nó được thực hiện để đảm bảo rằng daemon không có được thiết bị đầu cuối kiểm soát trên các hệ thống dựa trên System V.

Một lý do là quá trình cha mẹ có thể ngay lập tức chờ đợi_pid () cho đứa trẻ và sau đó quên nó đi. Khi đó, cháu nội chết, cha mẹ là init và nó sẽ đợi () cho nó - và đưa nó ra khỏi trạng thái zombie.

Kết quả là quá trình cha mẹ không cần phải biết về những đứa trẻ rẽ nhánh, và nó cũng làm cho nó có thể rẽ nhánh các quá trình chạy dài từ libs, v.v.

Cuộc gọi daemon () có lệnh gọi cha _exit () nếu thành công. Động lực ban đầu có thể là cho phép cha mẹ làm một số công việc phụ trong khi đứa trẻ đang daemon.

Nó cũng có thể dựa trên một niềm tin sai lầm rằng nó là cần thiết để đảm bảo daemon không có quá trình cha mẹ và được sửa chữa lại cho init - nhưng điều này sẽ xảy ra dù sao đi nữa khi cha mẹ chết trong trường hợp ngã ba.

Vì vậy, tôi cho rằng cuối cùng tất cả chỉ sôi sục theo truyền thống - một ngã ba duy nhất là đủ miễn là cha mẹ chết theo thứ tự ngắn nào.

Một cuộc thảo luận tốt về nó dường như có tại http://www.developerweb.net/forum/showthread.php?t=3025

Trích dẫn mlampkin từ đó:

... nghĩ về cuộc gọi setsid () như là cách "mới" để thực hiện (tách rời khỏi thiết bị đầu cuối) và cuộc gọi [second] fork () sau khi nó là dự phòng để đối phó với SVr4 ...

Có thể dễ hiểu hơn theo cách này:

• Nĩa đầu tiên và setsid sẽ tạo một phiên mới (nhưng ID tiến trình == ID phiên).
• Ngã ba thứ hai đảm bảo ID tiến trình! = ID phiên.