主页 / unix / 问题 / 446273
Accepted
Pyjong
Asked: 2018-05-27 23:38:43 +0800 CST

为什么守护进程没有关联的终端？

  • 772

我对创建 linux 守护进程的惯例有点困惑。人们大多同意使守护进程没有关联的终端。此外，在示例代码中，进程的父进程通常被杀死，而守护进程重新成为 init 的父进程。我没有问题理解这是这样做的方法，但是为什么？该进程没有关联的终端并且是初始化的直接子进程，这有什么好处？

daemon

1 个回答

  1. Best Answer

    https://en.wikipedia.org/wiki/SIGHUP

    1.进程没有关联终端有什么好处？

    在 POSIX 兼容的平台上，SIGHUP（“信号挂断”）是在进程的控制终端关闭时发送给进程的信号。（它最初是为了通知串行线路掉线的过程而设计的。）

    [...]

    在符合 POSIX 的系统上，[SIGHUP] 的默认操作是异常终止。

    如果我正确理解情况，则有两种不同的情况。

    明显的情况是，如果您关闭例如 GNOME Terminal 或 之类的终端仿真器mc，则会关闭伪终端设备的主端。这个闭包会在伪终端上产生一个挂断。这会影响从设备。受此终端控制的所有进程都将收到 SIGHUP。这不是上述情况。

    @JDePB指出第二种情况：如果关闭所有引用终端设备的文件描述符，它也会产生挂断。也就是说，如果您的守护进程关闭其 tty 的 FD（它应该关闭它），然后在其他具有 tty 出口的开放 FD 的进程上，您的守护进程将收到 SIGHUP，即使您的终端仿真器没有响应并离开伪终端的主端打开。通过清除 HUPCL可以为整个终端设备禁用此功能。

    还有vhangup()。似乎login调用它是为了尝试确保上一个会话不会干扰它。或者其他的东西。我并不完全清楚，因为这个调用是特定于 Linux 的，并且手册页非常非常短。

    2.并且是直接子init？

    如果接收 SIGHUP 的进程是 Unix shell，那么作为作业控制的一部分，它通常会拦截信号并确保所有停止的进程在将信号发送给子进程（更准确地说，进程组，在 shell 内部表示为一个“工作”），默认情况下会终止它们。

    • 1

相关问题