☰

如果進程無法自行守護進程，那麼在 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集成沒有問題；它只是運行。

親切的問候 - 安德烈亞斯

相關內容