☰

如果进程无法自行守护进程，那么在 init 脚本中创建后台作业是否是一个好习惯？

tag-icon • tag-icon init-script daemon
如果进程无法自行守护进程，那么在 init 脚本中创建后台作业是否是一个好习惯？

我对 *nix 相当陌生，并且遇到过需要删除多个进程的情况，这些进程应该 100% 地运行。到后台使用&.

我在 init.d 脚本中使用以下行来执行此操作（以用户身份运行user：

su -c 'process arg1 arg2 -w - | process2 arg1 -r - &' user

（其中 -w 写入 STDOUT、STDIN，-r 读取 STDOUT、STDIN）

具体来说，我知道这通常是不可接受的，因为这些过程没有很好地免受外部影响。

为“服务”创建后台作业是否可以接受？

我应该使用 FIFO/命名管道来处理进程间通信吗？

如果是这样，我是否仍然应该将这两个进程创建为后台作业？这稳定吗？

具体请参考这个邮件列表主题。

谢谢，

马特

答案1

具体来说，我知道这通常是不可接受的，因为这些过程没有很好地免受外部影响。

为“服务”创建后台作业是否可以接受？

如果没有其他方法（即服务不会自行分叉），那么可能是的。 Debianstart-stop-daemon有一个--background针对这种情况的参数：

   -b, --background
          Typically used with programs that don't  detach  on  their  own.
          This option will force start-stop-daemon to fork before starting
          the  process,  and  force  it  into  the  background.   WARNING:
          start-stop-daemon  cannot  check  the exit status if the process
          fails to execute for any reason. This is a last resort,  and  is
          only  meant  for  programs  that either make no sense forking on
          their own, or where it's not feasible to add the code  for  them
          to do this themselves.

答案2

由于第一个问题已经得到解答，我将集中讨论最后两个问题。

几天前，我遇到了类似的问题：我必须通过/etc/init.d脚本中的管道启动一些进程。为了解决这个问题，我研究了 RHEL6（daemon以及killproc）/etc/init.d/functions和 Debian（start-stop-daemon）。我了解到，两者都不能很好地处理管道。即使以某种方式有可能启动它们，但阻止它们却存在重大问题。因此我写了一个小工具pipexec。该程序启动了一系列程序，但其行为就像一个程序。示例：当SIGTERM发送a 时pipexec，它会杀死所有子级，然后再杀死它自己。还支持 pid 文件处理 - 这让您在与 RHEL6daemon和killproc.

我应该使用 FIFO/命名管道来处理进程间通信吗？如果是这样，我是否仍然应该将这两个进程创建为后台作业？这稳定吗？

我也考虑过这一点 - 但对我来说这太复杂了，而且当涉及到 fifos 的稳定性和可靠性时，我没有很好的经验（也许这是我的问题 - 但因此我很少使用它们;-)）

我pipexec用RHEL6集成没有问题；它只是运行。

亲切的问候 - 安德烈亚斯

相关内容