Linux - 带有 init 的 IPC

Question

init 进程作为 linux 系统上所有进程的祖先存在。这个过程是否有任何类型的 IPC 入口点？其他进程是否曾经出于任何原因使用 init 执行 IPC？

Answer 1

不要混淆进程和程序。有一个进程#1，但它可以运行许多不同的程序之一。

• 如果它systemd从 systemd 包运行程序：
  • 有一个可以通过 D-Bus 访问的内部 systemd API，它不能保证稳定并且不打算被 systemd 包之外的东西使用。
  • 它响应了一大套的信号，从SIGWINCH和SIGPWR到SIGRTMIN + 4。
• 如果它system-manager从nosh 包运行程序：
  • 它响应由 识别的相当大的信号子集，systemd在适用的情况下具有相同的含义。
• 如果它init从 upstart运行程序：
  • 有一个内部 upstart 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-read
  • initctl除了 System V 之外init，其他任何东西实际上都不是原生的，因为其他的（如果他们这样做的话）只将运行级别的概念实现为一种有限的向后兼容机制。
  • 正如其init程序的新贵手册页所说，该initctl机制没有很好的记录。甚至 System V 的init人也到处告诉人们只有 System Vinit包中的东西才能使用它。它没有帮助，而且，Debian的系统V维护从它搬迁/dev到/run。

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

• 该systemd程序是一个组合系统管理器、服务管理器和控制组管理器，因此程序使用 IPC 来处理 #1 有很多用途。新贵的init.
• system-manager相反，对于 nosh 来说，服务管理是由service-manager另一个进程中的另一个程序 ( )完成的，它具有自己的（与守护程序工具兼容的）API。因此，对进程 #1 进行 IPC 的唯一原因是系统状态管理，例如（例如）重新启动机器。

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

进一步阅读

• https://superuser.com/questions/886825/