为什么 nohup 对特定进程不起作用

Question

出于什么原因，nohup 不能在特定的内部开发流程上工作？

我使用它如下：

/usr/bin/nohup process_a &

我可以关闭执行它的终端，并通过 ps 看到它仍在运行。但是，注销并再次登录后，该进程不再运行。

我可以在不同的内部开发的 process_b 上运行相同的 nohup 命令，并且注销并重新登录不会结束该进程。它仍在运行。

我想知道 process_a 可能有什么“特殊”之处，以至于它无法在注销并再次登录后生存。进程 a 和 b 都打开 TCP 服务器套接字，并且还打开用于日志记录的文件描述符。

我尝试过使用 bash、tcsh 和 zsh shell，结果都相同。

出于什么原因，在 nohup 下运行的一个进程会在注销/登录时存活下来，而另一个则不会？我假设开发人员可以更改代码中的某些内容。

我们在相当严格的环境中运行 RHEL 6（screen、tmux 等不是可用的替代方案）。

更新：

process_a 在以下情况下仍然存在

杀死 -s HUP PID

所以在这种情况下 SIGHUP 似乎是通过 nohup 成功处理的。但它仍然在注销时死掉。

Answer 1

如果 process_a 的代码显式捕获 SIGHUP （挂断信号）或将其重置为默认处理程序（即无；即退出），这将解释您所看到的行为。要求开发人员搜索代码SIGHUP并查看它在做什么。

如果您可以在该程序上运行，您可能能够更好地诊断这一点strace，但是，由于您有“相当严格的环境”， strace因此可能不可用。如果您能够更快地进行测试并生成更多可操作的取证结果

1. 启动进程 ( nohup process_a &),
2. 记下报告的 PID，
3. 等待几秒钟或几分钟，
4. 验证进程是否正在使用已知的 PID 运行（例如，使用ps），
5. 做，kill -HUP PID
6. 重新检查流程，也许
7. 等待几秒钟或几分钟，然后再次重新检查该过程。

Answer 2

该进程在 nohup 下运行时无法在注销/登录后存活的具体原因是它利用了 Motif。尽管在此过程的环境中，GUI 没有被调用/实现，但代码最终在其 main()（c 代码）中使用了 XtAppMainLoop。也许 Motif 库对信号做了一些事情。

其他答案/评论中建议的其他原因：

该进程显式捕获/重置 SIGHUP

该进程使用 tty 设备