☰

Linux - 带 init 的 IPC

tag-icon • tag-icon init
Linux - 带 init 的 IPC

init 进程作为 Linux 系统上所有进程的祖先而存在。这个进程有任何类型的IPC入口点吗？其他进程是否出于某种原因与 init 进行 IPC？

答案1

不要将流程和程序混为一谈。有一个进程#1，但它可以运行多个不同程序之一。

  • 如果它正在运行systemdsystemd 包中的程序：
  • 如果它正在运行system-manager节目来自小吃包:
    • 它响应 所识别的相当大的信号子集systemd，在适用的情况下具有相同的含义。
  • 如果它正在运行init来自新贵的程序：
  • 如果它正在运行 Joachim Nilsson 的finit：
  • 如果运行的是系统 5，init则：
    • 它从 FIFO 读取命令消息initctl。
    • 它响应非常小的一组信号。

一些注意事项：

  • 信号 API 是由向进程 #1 发送信号的事物强制执行的。其中包括操作系统内核，它发送诸如SIGWINCH、SIGINT、 和 之类的内容SIGPWR，以及各种广泛使用的系统实用程序。
    • 两者都通过命令系统状态更改（例如关闭和关闭系统电源）的信号来扩展此systemd功能。system-manager
    • 并非所有程序都支持整套系统规定的信号。SIGPWR例如，暴发户没有提到回应。
    • finit识别一组不同的非系统强制扩展信号，包括SIGSTOP和SIGCONT。
  • 虽然 systemd 包没有实现initctl在作为进程 #1 运行的程序中实现 FIFO API，但它确实提供了兼容性垫片在其他进程，运行另一个程序，将该机制转换为本机 systemd 机制。 （nosh 工具集有自己的initctl-read兼容性 shim 类似地转换为 nosh 工具集系统管理的本机机制。）
    • initctl实际上，除了 System V 之外，其他任何东西都不是本机的init，因为其他系统（如果它们确实这样做的话）仅将运行级别的概念实现为有限的向后兼容性机制。
    • 正如其程序的新贵手册页init所说，该initctl机制没有得到很好的记录。甚至 System V 的init人们也到处告诉人们只有 System Vinit包中的东西才应该使用它。此外，Debian System V 维护者将其/dev从/run.

所以是的，程序使用进程 #1 执行 IPC。他们这样做的原因各不相同。

  • 该systemd程序是系统管理器、服务管理器和控制组管理器的组合，因此程序使用 IPC 来处理 #1 的目的有很多。对于暴发户来说也是如此init。
  • 对于开胃菜system-manager，相反，服务管理是由另一个程序完成的（service-manager进程中的另一个程序 ( ) 使用其自己的（与 daemontools 兼容的）API 完成的。所以使用进程 #1 进行 IPC 的唯一原因是系统状态管理，例如（例如）重新启动机器。

对于许多（不是全部）目的，最好坚持使用其他 API，使用传统的系统实用程序来执行诸如关闭和重新启动系统之类的操作，而不是在system-manager和systemd程序作为进程 #1 运行时发送它们理解的信号。

进一步阅读

相关内容