Linux

為什麼在服務的單元文件中使用分叉？

  • March 18, 2021

我的 nginx 單元文件如下，

[root@arif ~]# cat /usr/lib/systemd/system/nginx.service
[Unit]
Description=The nginx HTTP and reverse proxy server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
# Nginx will fail to start if /run/nginx.pid already exists but has the wrong
# SELinux context. This might happen when running `nginx -t` from the cmdline.
# https://bugzilla.redhat.com/show_bug.cgi?id=1268621
ExecStartPre=/usr/bin/rm -f /run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
KillSignal=SIGQUIT
TimeoutStopSec=5
KillMode=process
PrivateTmp=true

[Install]
WantedBy=multi-user.target

這裡，在該[Service]部分中，的值Type等於forking從這裡開始的意思，

以 ExecStart 啟動的程序會生成一個子程序，該子程序將成為服務的主程序。啟動完成後父程序退出。

我的問題是，

  • 為什麼服務會這樣做？
  • 這樣做有什麼好處？
  • 出了什麼問題Type=simple或其他類似的選擇？

為什麼服務會這樣做？

事實上，服務通常不會那樣做。除了這不是一個好的做法，而且“dæmonization”的想法確實是錯誤的之外，服務所做的並不是forking協議所要求的。他們弄錯了協議，因為他們實際上是在做其他事情forking，這通常是不必要地被硬塞到協議中的。

這樣做有什麼好處？

沒有。存在更好的準備通知協議，實際上沒有人正確地使用該協議。這個服務單位沒有這樣做，因為它是有利的。

出了什麼問題Type=simple或其他類似的選擇？

沒有。事實上，通常是使用forking準備協議是錯誤的。正如其他答案所聲稱的那樣，這不是最佳實踐。恰恰相反。

一個簡單的事實是，這是一個糟糕的工作中最好的一個，它可以應對仍然無法關閉的 nginx 行為。現在的大多數服務軟體，多虧了來自 IBM SRC、daemontools 和其他嚴肅的服務管理領域的 25 年的鼓勵，已經獲得了選項，甚至改變了它們的預設行為，而不是試圖愚蠢地“dæmonize”某些東西已經在 dæmon context 中。

但是，對於 nginx，情況仍然不是這樣。 daemon off不工作，可悲的是。就像許多軟體錯誤地將“non-dæmonize”模式與調試模式混為一談一樣（但現在通常不再這樣做），nginx 不幸地將其與其他事情混為一談，例如不處理其控制信號。到目前為止，人們已經為此努力了 5 年。

進一步閱讀

引用自：https://unix.stackexchange.com/questions/504342

相關問答

Linux

Systemd 超時，因為它沒有檢測到守護程序分叉

  • September 17, 2021
檢視問答
Linux

如何在 systemd 日誌中為共享標準輸出文件描述符的程序提供 PID？

  • January 21, 2021
檢視問答
Linux

在 Centos 機器上創建一個沒有密碼和主目錄的系統使用者

  • October 31, 2022
檢視問答
Linux

如果文件更改，如何自動重啟 systemd 服務？

  • October 24, 2022
檢視問答
Linux

警告：由於權限不足，部分日誌文件未打開

  • August 11, 2022
檢視問答
Linux

systemd-sysctl 和 sysctl 之間的區別

  • July 12, 2022
檢視問答