Init
Linux - 帶初始化的 IPC
init 程序作為 linux 系統上所有程序的祖先存在。這個過程是否有任何類型的 IPC 入口點？其他程序是否出於任何原因使用 init 進行 IPC？
不要將流程和程序混為一談。有一個程序#1，但它可以執行多個不同程序之一。
如果它
systemd從 systemd 包執行程序：如果它正在執行nosh 包中的
system-manager程序：
- 它響應由 辨識的相當大的信號子集，
systemd在適用的情況下具有相同的含義。如果它是
init從新貴執行程序：
- 有一個內部新貴 API，可通過 D-Bus 訪問。
- 它從
initctlFIFO 中讀取命令消息。- 它響應一小組信號。
如果它正在執行 Joachim Nilsson 的
finit：
- 它從
initctlFIFO 中讀取命令消息。- 它響應一小組信號。
如果它正在執行 System 5
init，則：
- 它從
initctlFIFO 中讀取命令消息。- 它響應非常小的一組信號。
一些注意事項：
信號 API 由將信號發送到程序 #1 的事物強制執行。其中包括作業系統核心，它發送諸如
SIGWINCH、SIGINT和之類的東西SIGPWR，以及各種廣泛使用的系統實用程序。
- 兩者
systemd和 nosh都system-manager通過命令系統狀態更改的信號（例如關閉和關閉系統電源）擴展了這一點。- 並非所有程序都支持全套系統規定的信號。例如，暴發戶沒有提及對 的響應
SIGPWR。finit辨識一組不同的非系統強制擴展信號，包括SIGSTOP和SIGCONT。儘管 systemd 包沒有
initctl在作為程序 #1 執行的程序中實現 FIFO API，但它確實在另一個程序中提供了一個**兼容性填充程序，執行另一個程序，將該機制轉換為本機 systemd 機制。（nosh 工具集有自己的兼容性填充程序，類似地轉換為 nosh 工具集系統管理的本機機制。）
initctl確實不是 System V 的原生系統init，因為其他系統（如果他們這樣做的話）僅將執行級別的概念實現為有限的向後兼容機制。- 正如其
init程序的新貴手冊頁所說，該initctl機制沒有得到很好的記錄。即使是 System V 的init人也四處告訴人們只有 System Vinit包中的東西才能使用它。此外，Debian System V 維護人員將其/dev從/run.所以是的，程序使用程序#1 進行 IPC。他們這樣做的原因各不相同。
- 該
systemd程序是系統管理器、服務管理器和控制組管理器的組合，因此程序使用 IPC 處理 #1 有很多用途。新貴也是一樣init。- 相反，對於 nosh 來說
system-manager，服務管理是由service-manager另一個程序中的另一個程序 ( ) 使用自己的（daemontools 兼容的）API 完成的。因此，使用程序#1 進行 IPC 的唯一原因是用於系統狀態管理，例如（例如）重新啟動機器。對於許多（不是全部）目的，最好堅持使用其他 API，使用傳統的系統實用程序來執行諸如關閉和重新啟動系統之類的操作，而不是在
system-manager和systemd程序作為程序 #1 執行時發送它們所理解的信號。進一步閱讀