我應該如何在后台運行Golang進程？

Question

這個問題並不是嚴格的編程相關，但對程序員來說肯定很重要。

我寫了一個簡單的smtp服務器，當我從控制台運行它一切都很好，除了它阻止命令行。

我知道我可以通過它來運行它

nohup ... &

或通過screen / tmux等

但問題是，我應該如何實現我在后台運行的程序，系統管理員很樂意設置它並管理流程？

有些人比我更有經驗，在golang-nuts上寫道，他們不使用fork等，並使用monit等形式的“包裝”。

目標平台是基於Debian的，盒子上的所有其他東西都是基於init.d的。

該主題的任何好資源或編寫良好的示例項目的來源？

Answer 1

正如Nick所說， Supervisord是一個很好的選擇，在我的經驗中也很有效。

尼克提到了分叉問題 - 分叉本身工作得很好AFAICT。 問題不是分叉，而是放棄特權。 由於Go運行時啟動goroutine被多路復用的線程池的方式（當GOMAXPROX> 1時），setuid系統調用不是刪除權限的可靠方法 。

相反，您應該以非特權用戶身份運行程序，並使用setcap實用程序為其授予所需的權限。

例如，要允許綁定到低端口號（如80），需要在可執行文件上運行setcap一次： sudo setcap 'cap_net_bind_service=+ep' /opt/yourGoBinary

您可能需要安裝setcap： sudo aptitude install libcap2-bin

Answer 2

已有很好的答案，但我會添加一些額外的信息。

您無需在Debian上安裝其他軟件（如supervisord來處理后台處理過程。

Debian附帶了一個名為start-stop-daemon的工具，它是在init.d腳本中啟動守護進程的標准方法。 如果程序不自行執行，它還可以將該過程置於后台。 看看--background選項。

使用/etc/init.d/skeleton作為init腳本的基礎，但更改do_start()函數，如下所示：

start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile \
    --background --exec $DAEMON --test > /dev/null \
            || return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile \
    --background --exec $DAEMON -- $DAEMON_ARGS \
            || return 2

我還添加了--make-pidfile選項，它為您創建PID文件。

如果您需要以安全的方式切換到其他用戶，還有--chuid選項。

在Ubuntu和RHEL / CentOS / SL 6.X上，最簡單的方法是編寫一個upstart作業配置文件。 只需將exec /usr/sbin/yourprogram放在/etc/init/yourprogram.conf配置文件中即可。 使用暴發戶，無需在后台強制執行該程序。 不要使用傳統守護進程添加expect fork或expect daemon進程。 使用upstart，如果進程不分叉則更好。

Answer 3

我不久前寫了一篇關於這篇文章的博文 。 守護進程的想法對我來說似乎不對，因為它會讓你擔心很多其他事情（例如，當它失敗時會發生什么？你如何管理進程重啟？你如何處理日志，工作目錄，核心，系統重啟等...）

事實證明，如果你不努力做到這一切，事情變得容易多了。

Answer 4

根據我的經驗， Supervisord非常適合這一點。

你編寫你的應用程序在命令行上運行，打印東西等，supervisord負責所有的守護，重新啟動，如果它出錯，速率限制等，等等

我認為以傳統的unix方式將程序轉移到后台是很困難的，因為運行時在運行main()例程之前啟動了一些線程

Answer 5

但問題是，我應該如何實現我在后台運行的程序，系統管理員很樂意設置它並管理流程？

這里有幾點想法。

提供包和存儲庫

安裝軟件是一回事，維護和運行它是一個完全不同的故事。 當然，我可以下載一個zip，解壓縮，將文件放入正確的目錄（請記住，軟件包通常分散在整個文件系統中），創建一個系統用戶來運行守護進程，設置相應的權限。 但這很乏味，容易出錯（這將導致大量的門票涌入，比如“呸！不跑！修復它！”）並且如果要在許多系統上安裝該軟件，則幾乎不實用。

所以我們需要一個包來降低采用的障礙。 為這些軟件包提供存儲庫通常不是火箭科學，使安裝和/或更新更容易。 “下載 - >分發 - >安裝/更新”和單個命令/服務器之間有區別

$ awesomePm update coolApplication

至少為RedHat和基於Debian的系統提供包。 就個人而言，我會選擇CentOS（這會使你的軟件包兼容幾乎所有RHEL派生）和基本的Debian。 后者應該為Ubuntu提供一個包也很簡單。 由於我不再使用Debian或派生，我不太確定它們是否真正兼容，當我上次構建.deb時出現啟動問題。

提供適當的文件 。 記錄安裝的內容，位置和原因。 提供相應文檔的鏈接。 manpage對依賴項的引用就足夠了。 這樣，您甚至可以啟用最缺乏經驗的管理員來配置您的包。

使用最防守，理智的默認值 。

關於golang的特別說明 ：默認情況下，大多數包構建工具都會刪除包中包含的二進制文件。 Go不支持，所以請注意這里。

完成

沒有什么比不完整的包更煩人了。

盡可能使用syslog並遵守它的約定。 這樣，您的日志將被放置到系統管理員期望的位置，並且如果自動過期則會處理它們，從而阻止您的應用程序使磁盤運行完全。 如果系統管理員想要對應用程序的日志進行特殊處理，他將以這種方式進行配置。

不要通過您的應用程序旋轉日志。 用戶可以選擇如何處理它們（可能與其SLA相關）。 即使您將日志輪換為可配置的方式，管理員也必須學習如何配置它 - 這會引入不必要的冗余。

如果必須寫入日志文件，請遵循目標系統的日志記錄策略並提供日志輪換配置文件 。 您不希望應用程序成為導致停機的原因，因為機器的磁盤空間不足，對嗎？

使用系統工具而不是重新發明輪子。 如果您的應用程序需要進行一些維護，請不要在應用程序中使用調度程序。 編寫一個專門的維護工具（單片應用程序是如此'00s）並利用cron 。 特別是將相應文件添加到/etc/cron*目錄之一。

提供適當的 init腳本！ 這樣，管理員可以使用眾所周知的工具（如systemctl來管理應用程序的啟動和關閉。 當你不得不su用戶或使用sudo -u在啟動時調用shell腳本時，這非常煩人。 即使這個腳本被稱為@onboot ，與標准的偏差也很煩人。 僅僅因為啟動方法有效並不意味着它應該被使用。

添加SE-Linux配置文件的獎勵積分！

應該不言而喻，但我經常看到配置錯誤的包，所以： 測試你的包！ 從最小的目標操作系統安裝開始，安裝包並確保它按預期運行。 檢查您提供的每個配置。

如果您計划將一個軟件包放入官方Debian存儲庫，您應該計划一些時間：Debian穩定的原因是對軟件包的要求非常緊張，即使您滿足所有要求，也必須全部從測試到不穩定到穩定的方式。

准確一點

不要僅僅因為方便而使用現有用戶。 如果您創建Web應用程序，請不要重復使用“apache”或“www”用戶。 創建專用於您的包的用戶， 並將此用戶添加到相應的組 。

堅持最不必要的權限原則。 幾乎沒有理由擁有二進制世界可執行文件，更不用說世界可寫（這將是一個極端的安全漏洞）。 如果應用程序沒有運行，你經常在這里看到的是建議將權限設置為[0] 777，這允許每個用戶對文件進行任何修改。 實際上，幾乎沒有理由讓二進制文件可以寫入任何用戶：root，無論如何都進行更新，總是可以寫任何東西。 因此二進制文件的權限應為0550 。 該原則也適用於數據目錄等。 在這里投入一些時間和精力。 您不希望您的應用成為攻擊成功的載體，對嗎？ 即使是潛在的安全風險也會對您和您的聲譽產生影響。 我傾向於將所有數據文件設置為0600用於需要由應用程序的系統用戶寫入的文件， 0400用於只讀文件， 0500用於二進制文件。 然后，我會詳細分析組權限應該是什么。 例如：組可能會更改Web應用程序的各個模板 - 但很可能不是資源目錄子樹的目錄結構。

如果你付出了安全努力，你就會增加信任。 請注意，在采用包之前，通常會檢查包的安全性影響。

堅持FHS （!!）！ 即便如此：只是因為你可以在/opt/yourapplication下做任何事情，這樣做並不總是一個好主意。 而是分別安裝到/usr和/var （假設在啟動時不需要您的應用程序）。

如果您有依賴項，請定義它們。 不要僅僅假設存在包裹。

如果您對本地SMTP服務器具有依賴關系，請不要聲明對postfix的依賴關系。 也許管理員更喜歡sendmail（無論出於何種原因）。 因此，請定義對mail-transport-agent （Debian）或mta （RH，iirc）的依賴關系。

結論

這就是我對優秀軟件的期望 - 與現有軟件很好地集成，並且無需學習冗余配置即可輕松安裝，維護，配置和運行。 如果我看到一個包的SELinux配置文件，那確實給了供應商一個獎勵 - 除非配置文件非常草率，它表明供應商的安全性非常嚴重。