摘要：在模塊中有個函數，通過可以執行命令及其相關選項，同時提供了創建子進程的一些選項，其中選項則與我們的需求密切相關。在文件中設置了函數，目的是避免父進程等待子進程退出。不同會話的進程無法通過通信，因此父子進程相隔離。

在node工程部署中，常常涉及到三方：本地客戶端、跳板機和服務器（集群）。在通過git觸發gitlab hook腳本后，需要在跳板機中執行相應的ssh命令執行shell文件啟動node服務器，這需要使用一個常用的命令setsid，這樣當ssh命令執行完畢shell退出后，node服務器仍正常運行，此時node服務進程就是一個最典型的daemon進程（后臺服務進程）。

那么，在node項目中，如何創建一個daemon進程呢？最簡單的方式，其實就是采用類似上文中介紹的方式：

require("child_process").exec("setsid node app.js >/dev/null 2>&1 &");

這樣可以通過執行shell的方式實現daemon進程。不過本文的重點并不是介紹這種“命令行”的方式實現daemon進程，而且本文會詳細講述daemon進程的創建原理，且看下文。

在當前業務中，之所以需要創建daemon進程就是為了保證中斷創建該進程的父進程（ctrl+c）或者父進程執行完畢后并不影響daemon進程的執行。下文介紹兩種實現方式，實現原理細節上有些出入。

下文中的所有討論都是在linux環境下進行。

在linux系統中，父進程創建出子進程，此時父進程若退出，此時子進程則變為孤兒進程，其ppid變為1，即成為init進程的子進程。在node環境下，如果不針對子進程的stdio做一些特殊處理父進程其實不會真正退出，而是直到子進程執行完畢后再退出。之所以出現這種情況是由于node創建子進程時默認會通過pipe方式將子進程的輸出導流到父進程的stream中（childProcess.stdout、childProcess.stderr），提供在父進程中輸出子進程消息的能力。

因此，解決此種問題可給子進程的stdio重新賦值:

file: parent.js

let cp = require("child_process");
const sp = cp.spawn("node",["./c.js"],{
    stdio: [process.stdin,process.stdout,process.stderr]
});

setTimeout(()=>{console.log("parent out")},5000);

--------------
file: c.js

setTimeout(()=>{
    console.log("children exit");
},10000)

通過在parent.js中設置子進程的stdio為當前終端(其實繼承了父進程的stdio)，這樣父進程在5s后退出，此時子進程的ppid變為1，10s后子進程退出。

上述實現只滿足“父進程正常退出，子進程成為守護進程”的情況，一旦通過“ctrl+c”的方式終端父進程，子進程仍會退出，這還是與node底層實現有關。默認“ctrl+c”觸發SIGINT信號，父進程接受信號后發送給子進程，如果子進程存在SIGINT偵聽函數，則會執行該函數，否則執行exit系統調用子進程退出。因此，如果要讓子進程在接收到SIGINT信號不退出，只需要不作處理即可：

file: c.js

process.on("SIGINT",function(){
    console.log("child sigint");
});

setTimeout(()=>{
    console.log("children exit");
},10000)

以上實現，可以滿足我們最初指定的目標：“父進程退出或者中斷，子進程仍正常運行”。

node官方提供了創建daemon進程的相關API，如果不仔細閱讀文檔還真不容易發現該特性。在child_process模塊中有個spawn函數，通過spawn可以執行shell命令及其相關選項，同時spawn提供了創建子進程的一些選項，其中“detached”選項則與我們的需求密切相關。

detached選項可以讓node原生幫我們創建一個daemon進程，設置datached為true可以創建一個新的session和進程組，子進程的pid為新創建進程組的組pid，這與setsid起到相同的作用。此時的子進程已經和其父進程屬于兩個session，因此父進程的退出和中斷信號不會傳遞給子進程，子進程不會接受到父進程的中斷信號自然也不會退出。當父進程結束之后，子進程變為孤兒進程從而被init進程接收，ppid設置為1。

file: parent.js

let cp = require("child_process");
const sp = cp.spawn("node",["./c.js"],{
    detached: true,
    stdio: [process.stdin,process.stdout,process.stdout]
});

sp.unref();
setTimeout(()=>{console.log("parent out")},5000);

----------------------
file: c.js

setTimeout(()=>{
    console.log("children exit");
},100000)

此時，c.js文件并未設置SIGINT事件偵聽函數，在父進程中斷后仍會正常運行，正是由于其和父進程分屬于兩個session。

在parent.js文件中設置了sp.unref()函數，目的是“避免父進程等待子進程退出”。那么為何會出現上述情況呢？這與node的事件循環有關，讓父進程的事件循環排除對ChildProcess子進程對象的引用，可以使父進程多帶帶退出。

為什么上文介紹的兩個方法都可以實現daemon進程呢？這還得回到系統層面進行分析。在linux系統創建一個daemon進程需要幾個步驟：

父進程創建子進程，父進程退出，讓子進程成為孤兒進程，ppid=1

通過setsid命令或函數在子進程中創建新的會話和進程組

設置當前目錄

設置文件權限，并關閉父進程繼承打開的fd

所謂會話和進程組，則是在linux多任務多用戶下的概念。不同會話的進程無法通過通信，因此父子進程相隔離。而執行setsid命令則讓子進程有了新的特性：

子進程脫離父進程所在的session控制，兩者獨立存在互不影響

子進程脫離父進程所在的進程組

子進程脫離原先的命令行終端，終端退出不影響子進程

下面再回顧方法一與方法二的區別，發現方法一其實并不是真正的daemon進程，只是通過偵聽相關中斷信號并設置nop函數（不執行默認的中斷行為）保證子進程繼續運行而已；而方法二則是標準的deamon進程創建方式，優先使用！