Go Exec 殭屍與孤兒進程詳情 - go,exec,unix,進程 WilburXu 動態日志

動態

詳情

返回

Go Exec 殭屍與孤兒進程 - 動態詳情

06:05 下午 · 11月 06 ,2025

原文地址：Go Exec 殭屍與孤兒進程

最近，使用 golang 去管理本地應用的生命週期，期間有幾個有趣的點，今天就一起看下。

場景一

我們來看看下面兩個腳本會產生什麼問題：

創建兩個 shell 腳本

start.sh

#!/bin/sh
sh sub.sh

sub.sh

#!/bin/sh
n=0
while [ $n -le 100 ]
do
  echo $n
  let n++
  sleep 1
done

執行腳本

輸出結果

$ ./start.sh 
0
1
2
...

進程關係

查看進程信息

ps -j

USER   PID    PPID   PGID   SESS  JOBC  STAT   TT     TIME     COMMAND
root   31758  31346  31758  0     1     S+     s000   0:00.00  /bin/sh ./start.sh
root   31759  31758  31758  0     1     S+     s000   0:00.01  sh sub.sh

sub.sh 的父進程（PPID）為 start.sh 的進程id（PID）
sub.sh 和 start.sh 兩個進程的 PGID 是同一個，（屬一個進程組）。

刪除 `start.sh` 的進程

kill -9 31758

# 再查看進程組
ps -j

## 返回
USER     PID       PPID  PGID     SESS  JOBC   STAT    TT       TIME     COMMAND
root     31759     1     31758    0      0     S       s000     0:00.03  sh sub.sh

start.sh 進程不在了
sub.sh 進程還在執行
sub.sh 進程的 PID 變成了 1

問題1：

那sub.sh 這個進程現在屬於什麼？

場景二

假設sub.sh 是實際的應用， start.sh 是應用的啓動腳本。

那麼，golang 是如何管理他們的呢？我們繼續看看下面關於golang的場景。

在上面兩個腳本的基礎上，我們用golang 的 os/exec庫去調用 start.sh腳本

package main

import (
    "context"
    "log"
    "os"
    "os/exec"
    "time"
)

func main()  {
    cmd := exec.CommandContext(context.Background(), "./start.sh")

  // 將 start.sh 和 sub.sh 移到當前目錄下
    cmd.Dir = "/Go/src/go-code/cmd/"
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    if err := cmd.Start(); err != nil {
        log.Printf("cmd.Start error %+v \n", err)
    }

    for {
        select {
        default:
            log.Println(cmd.Process.Pid)
            time.Sleep(2 * time.Second)
        }
    }
}

執行程序

go run ./main.go

查看進程

ps -j

USER   PID    PPID   PGID     SESS  JOBC  STAT   TT      TIME     COMMAND
root   45458  45457  45457    0     0     Ss+    s004    0:00.03  ...___1go_build_go_code_cmd
root   45462  45458  45457    0     0     S+     s004    0:00.01  /bin/sh ./start.sh
root   45463  45462  45457    0     0     S+     s004    0:00.03  sh sub.sh

發現 go 、 start.sh 、sub.sh 三個進程為同一個進程組（同一個 PGID）

父子關係為： main.go -> start.sh -> sub.sh

刪除 `start.sh` 的進程

實際場景，有可能啓動程序掛了，導致我們無法監聽到執行程序的情況，刪除start.sh進程，模擬下場景：

kill -9 45462

再查看進程

ps -j

USER   PID    PPID   PGID     SESS  JOBC  STAT   TT      TIME     COMMAND
root   45458  45457  45457    0     0     Ss+    s004    0:00.03  ...___1go_build_go_code_cmd
root   45462  1      45457    0     0     S+     s004    0:00.01  (bash)
root   45463  45462  45457    0     0     S+     s004    0:00.03  sh sub.sh

發現沒， start.sh 的 PPID 為1
即使 start.sh 的 PPID變成了1 ，log.Println(cmd.Process.Pid) 還持續的輸出 .

問題2:

那如果 PPID為1 ，golang程序不就無法管理了嗎？即使 sub.sh 退出也不知道了，那要如何處理？

問題分析

兩個場景中，都有一個共同的點，就是 PPID 為1，這妥妥的成為沒人要的娃了——孤兒進程
場景二中，如果 cmd的沒有進程沒有被回收，go程序也無法管理，那麼start.sh就成為了佔着茅坑不拉屎的子進程——殭屍進程

那究竟什麼是孤兒進程 和 殭屍進程？

孤兒進程

在類 UNIX 操作系統中，孤兒進程（Orphan Process）指：是在其父進程執行完成或被終止後仍繼續運行的一類進程。

為避免孤兒進程退出時無法釋放所佔用的資源而僵死，任何孤兒進程產生時都會立即為系統進程 init 或 systemd 自動接收為子進程，這一過程也被稱為收養。在此需注意，雖然事實上該進程已有init作為其父進程，但由於創建該進程的進程已不存在，所以仍應稱之為孤兒進程。孤兒進程會浪費服務器的資源，甚至有耗盡資源的潛在危險。

解決&預防

終止機制：強制殺死孤兒進程（最常用的手段）；
再生機制：服務器在指定時間內查找調用的客户端，若找不到則直接殺死孤兒進程；
超時機制：給每個進程指定一個確定的運行時間，若超時仍未完成則強制終止之。若有需要，亦可讓進程在指定時間耗盡之前申請延時。
進程組：因為父進程終止或崩潰都會導致對應子進程成為孤兒進程，所以也無法預料一個子進程執行期間是否會被“遺棄”。有鑑於此，多數類UNIX系統都引入了進程組以防止產生孤兒進程。

殭屍進程

在類 UNIX 操作系統中，殭屍進程（zombie process）指：完成執行（通過exit系統調用，或運行時發生致命錯誤或收到終止信號所致），但在操作系統的進程表中仍然存在其進程控制塊，處於"終止狀態"的進程。
正常情況下，進程直接被其父進程 wait 並由系統回收。而殭屍進程與正常進程不同，kill 命令對殭屍進程無效，並且無法回收，從而導致資源泄漏。

解決&預防

收割殭屍進程的方法是通過 kill 命令手工向其父進程發送SIGCHLD信號。如果其父進程仍然拒絕收割殭屍進程，則終止父進程，使得 init 進程收養殭屍進程。init 進程週期執行 wait 系統調用收割其收養的所有殭屍進程。

查看進程詳情

# 列出進程
ps -l

USER：進程的所屬用户
PID：進程的進程ID號
RSS：進程佔用的固定的內存量 (Kbytes)
S：查看進程狀態
CMD：進程對應的實際程序

進程狀態（S）

R：運行 Runnable (on run queue) 正在運行或在運行隊列中等待
S：睡眠 Sleeping 休眠中，受阻，在等待某個條件的形成或接受到信號
I：空閒 Idle
Z：僵死 Zombie（a defunct process) 進程已終止，但進程描述符存在，直到父進程調用wait4()系統調用後釋放
D：不可中斷 Uninterruptible sleep (ususally IO) 收到信號不喚醒和不可運行，進程必須等待直到有中斷髮生
T：終止 Terminate 進程收到SIGSTOP、SIGSTP、 SIGTIN、SIGTOU信號後停止運行運行
P：等待交換頁
W：無駐留頁 has no resident pages 沒有足夠的記憶體分頁可分配
X：死掉的進程

Go解決方案

採用殺掉進程組（kill process group，而不是隻 kill 父進程，在 Linux 裏面使用的是 kill -- -PID）與進程wait方案，結果如下：

package main

import (
    "context"
    "log"
    "os"
    "os/exec"
    "syscall"
    "time"
)

func main() {

    ctx := context.Background()
    cmd := exec.CommandContext(ctx, "./start.sh")
  
    // 設置進程組
    cmd.SysProcAttr = &syscall.SysProcAttr{
        Setpgid: true,
    }

    cmd.Dir = "/Users/Wilbur/Project/Go/src/go-code/cmd/"
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    if err := cmd.Start(); err != nil {
        log.Printf("cmd.Start error %+v \n", err)
    }

    // 監聽進程wait
    errCmdCh := make(chan error, 1)
    go func() {
        errCmdCh <- cmd.Wait()
    }()

    for {
        select {
        case <-ctx.Done():
            log.Println("ctx.done")
            pid := cmd.Process.Pid
            if err := syscall.Kill(-1*pid, syscall.SIGKILL); err != nil {
                return
            }
        case err := <-errCmdCh:
            log.Printf("errCmdCh error %+v \n", err)
            return
        default:
            log.Println(cmd.Process.Pid)
            time.Sleep(2 * time.Second)
        }
    }
}

剖析 cmd.Wait() 源碼

在 os/exec_unix下：

var (
    status syscall.WaitStatus
    rusage syscall.Rusage
    pid1   int
    e      error
    )

for {
    pid1, e = syscall.Wait4(p.Pid, &status, 0, &rusage)
    if e != syscall.EINTR {
        break
    }
}

進行了 syscall.Wait4對系統監聽，正如"僵死 Zombie（a defunct process) 進程已終止，但進程描述符存在，直到父進程調用wait4()系統調用後釋放"，所説一致。

總結

嚴格地來説，殭屍進程並不是問題的根源，罪魁禍首是產生出大量殭屍進程的那個父進程。

因此，當我們尋求如何消滅系統中大量的殭屍進程時，更應該是在實際的開發過程中，思考如何避免殭屍進程的產生。

參考：

https://pkg.go.dev/syscall

https://cs.opensource.google/...;l=279

https://pkg.go.dev/os/exec

exec , go , 進程 , unix

WilburXu 動態日志

@wilburxu

標簽

go (184)

進程 (14)

unix (3)

exec (2)

動態

Go Exec 殭屍與孤兒進程 - 動態詳情

場景一

創建兩個 shell 腳本

執行腳本

輸出結果

進程關係

刪除 `start.sh` 的進程

問題1：

場景二

執行程序

查看進程

刪除 `start.sh` 的進程

再查看進程

問題2:

問題分析

孤兒進程

解決&預防

殭屍進程

解決&預防

查看進程詳情

進程狀態（S）

Go解決方案

總結

參考：

Add a new 評論

WilburXu 動態日志

@wilburxu

標簽

go (184)

進程 (14)

unix (3)

exec (2)

動態

Go Exec 殭屍與孤兒進程 - 動態 詳情

場景一

創建兩個 shell 腳本

執行腳本

輸出結果

進程關係

刪除 start.sh 的進程

問題1：

場景二

執行程序

查看進程

刪除 start.sh 的進程

再查看進程

問題2:

問題分析

孤兒進程

解決&預防

殭屍進程

解決&預防

查看進程詳情

進程狀態（S）

Go解決方案

總結

參考：

Add a new 評論

Go Exec 殭屍與孤兒進程 - 動態詳情

刪除 `start.sh` 的進程

刪除 `start.sh` 的進程