Linux 上敲一條ps -ef第一列數(shù)字從 1 開始排2 是kthreadd緊接著ksoftirqd、kworker、migration一串帶方括號的內核線程再往后才是systemd、sshd、nginx這些熟面孔。不少人第一次認真盯著這份列表看心里都會冒出同一個疑問0 號進程跑哪兒去了內核源碼里明明有創(chuàng)建它的代碼為什么在進程列表里翻不到這個問題的答案其實就是整條 Linux 啟動過程最核心的一段鏈路。Linux 系統(tǒng)里進程與 PID 的對應關系是每個從業(yè)者的基本功而 PID 0、PID 1、PID 2 這三個特殊號段剛好把從內核第一條 C 指令到第一個用戶態(tài)程序的完整路徑串了起來。搞清楚它們的關系你就能回答一連串平時很容易被含糊帶過的問題為什么/proc/0不存在、為什么systemd一定是 1 號、為什么內核線程的父進程都是 2、容器里的 PID 1 又為什么跟宿主機的不一樣。這篇文章面向三類人剛接手 Linux 服務器、想補上底層認知的運維同學準備面試、被問過init 是怎么起來的的后端開發(fā)以及需要定制啟動流程、精簡系統(tǒng)鏡像的嵌入式工程師。下面按身份識別 → 源碼鏈路 → 動手驗證 → 故障排查 → 落地場景的順序展開每個環(huán)節(jié)我都會給出可以直接復制執(zhí)行的命令和關鍵源碼位置。1. 三個特殊 PID 的身份卡與職責邊界1.1 為什么 /proc 目錄里死活找不到 PID 0先說結論PID 0 不是一個可以被調度、被殺死、被觀察的常規(guī)進程它是內核為兩個用途預留的特殊編號。第一個用途是承載那份靜態(tài)定義的init_task結構體它位于內核源碼init/init_task.c長這樣struct task_struct init_task INIT_TASK(init_task); EXPORT_SYMBOL(init_task);這份結構體在編譯期就被塞進內核數(shù)據(jù)段沒有經過動態(tài)內存分配也沒有走正規(guī)的 PID 分配流程。正規(guī)的 PID 分配是alloc_pid()把新進程掛進init_pid_ns的 IDR 索引結構而init_task的 pid 字段直接被初始化為 0壓根沒進哈希表。/proc的目錄項是按 PID 命名空間里的哈希表生成的表里沒有它自然也就沒有/proc/0。同理find_task_by_vpid(0)返回空kill 0發(fā)的其實是給當前進程組而不是 0 號進程。第二個用途是每個 CPU 上的idle 線程。多核機器上每個邏輯核都得有一個沒事干時待著的執(zhí)行流用來在 CPU 空閑時執(zhí)行指令讓它進入低功耗狀態(tài)或者直接把核讓出去。這些 idle 線程在fork_idle()里創(chuàng)建pid 同樣被寫成 0命令名格式是swapper/NN 是 CPU 編號。提示top里那個id百分比列展示的就是 idle 線程在跑的時長占比但 idle 線程本身不會作為一個進程出現(xiàn)在top的進程列表里因為它沒有/proc目錄項采不到它的統(tǒng)計。這就解釋了一個常見的困惑有人用cat /proc/0/status報No such file or directory用ls /proc | sort -n | head發(fā)現(xiàn)最小的數(shù)字是 1然后就懷疑是不是自己環(huán)境被裁剪過。沒有任何正常的 Linux 都是這樣。想看 idle 線程的蹤跡去/proc/sched_debug或者top按1展開每核視圖能看到swapper名字掛在各個核下面。還有個小細節(jié)值得記住init_task同時也是內核進程鏈表的鏈表頭。內核里遍歷所有進程用的for_each_process()起點就是init_task因為那份結構體的tasks字段在鏈接時被初始化成一個自環(huán)。所以內核代碼里必須有一個 PID 0 存在哪怕它在用戶空間完全不可見——它是整個進程數(shù)據(jù)結構世界的地基。1.2 PID 1 與 PID 2 同源分流一次內核線程創(chuàng)建兩種人生rest_init()里有兩次關鍵的kernel_thread()調用前后腳創(chuàng)建了兩個進程它們分別拿到 PID 1 和 PID 2然后在極短的時間內走上完全不同的道路。拿到PID 1的那個進程函數(shù)入口是kernel_init。它最初也是一個徹頭徹尾的內核線程——沒有用戶態(tài)地址空間跑在內核棧上。但它接下來會做一件事通過run_init_process()去execve一個用戶空間的程序把整個進程的地址空間替換掉。execve不改變 PID于是 PID 1 從內核線程平滑過繼成了用戶態(tài)第一個進程。執(zhí)行完這步之后它就是你我熟悉的systemd或者sysvinit、OpenRC、s6視發(fā)行版而定。拿到PID 2的那個進程函數(shù)入口是kthreadd。它這輩子都不會執(zhí)行execve永遠留在內核態(tài)任務只有一個充當所有內核線程的生產車間。內核模塊、驅動、子系統(tǒng)需要后臺線程時不直接調用底層創(chuàng)建接口而是把請求塞進kthread_create_list鏈表喚醒kthreadd由它統(tǒng)一在create_kthread()里 fork 出新的內核線程。所以你會看到ksoftirqd/0、kworker/0:0、kswapd0、kblockd這些家伙的父進程全是 2。對比項PID 0PID 1PID 2內核符號init_task/fork_idlekernel_initkthreadd創(chuàng)建方式編譯期靜態(tài)定義 每核fork_idlekernel_thread/user_mode_threadkernel_thread父進程無PID 0PID 0是否進入用戶態(tài)否是通過execve否終身內核態(tài)/proc是否可見不可見可見可見調度優(yōu)先級最低純 idle普通普通典型命令名swapper/Nsystemd/initkthreadd這張表建議直接記住面試被問到PID 0 是什么的時候能一口氣把靜態(tài)定義和 idle 兩個身份都說出來基本就穩(wěn)了。很多人只知道第一個身份答完就卡住了。1.3 三者之間的父子與繼承關系到底怎么算從血緣上看PID 1 和 PID 2 的父進程都是 0。這不是嘴上說說內核里寫得明明白白——rest_init()里那段代碼是在start_kernel()的調用上下文里跑的而start_kernel()的執(zhí)行流最終會變成 idle 線程也就是 PID 0。換句話說先有 00 生了 1 和 2然后 0 退居幕后去當 idle。這個順序有個硬性要求必須先創(chuàng)建 PID 1再創(chuàng)建 PID 2。原因寫在內核注釋里——init 進程本身后續(xù)會需要創(chuàng)建內核線程如果先把它調度起來而kthreadd還沒就緒kthread_create()就會卡死。所以rest_init()里的寫法是創(chuàng)建kernel_init后立刻給它打上PF_NO_SETAFFINITY標志并綁到啟動核上創(chuàng)建kthreadd并記錄kthreadd_task指針最后用complete(kthreadd_done)通知kernel_init兄弟就位了你可以繼續(xù)了。你可以在自己的機器上直接驗證這層關系grep -E ^(Name|Pid|PPid) /proc/1/status grep -E ^(Name|Pid|PPid) /proc/2/status兩臺正常的機器上這兩條命令的PPid都會輸出 0。這是最直接的證據(jù)——用戶空間里唯一允許父進程是 0的進程就是這兩個。從繼承關系上看兩者分叉之后又各自開枝散葉。PID 1 是所有用戶態(tài)進程的祖先容器里的除外后面會講PID 2 是所有內核線程的祖先。你隨便挑一個內核線程看它的PPid基本都是 2除非它被顯式改過父進程。反過來除了 PID 1 和 PID 2任何進程的PPid都不可能是 0一旦你發(fā)現(xiàn)有第三個進程的父進程是 0那這臺機器就值得好好查一查了。2. 從內核第一條指令到第一個用戶進程的完整鏈路2.1 上電到 start_kernel 之間機器都干了些什么要理解 0/1/2 的誕生得先把鏡頭往前拉一點。按下電源之后CPU 從一個固定的物理地址開始取指跑的是主板固件傳統(tǒng) BIOS 或現(xiàn)在的 UEFI。固件做完自檢、枚舉設備、初始化內存控制器然后按啟動順序找到可引導設備把上面的引導加載程序絕大多數(shù)發(fā)行版用 GRUB2讀到內存里執(zhí)行。GRUB2 的工作分兩段。第一段很小塞在磁盤頭部作用是把自己更大的第二段加載進來。第二段讀配置文件把用戶選中的內核鏡像和配套的initramfs或initrd一起載入內存然后跳進內核入口。這一階段常被忽略的一件事是內核鏡像并不是裸的 ELF 可執(zhí)行文件它前面套了一層自解壓頭啟動時會先在臨時緩沖區(qū)里把壓縮過的內核decompress_kernel()展開屏幕上那行Decompressing Linux... Parsing ELF... done.就是它干的活。解壓完成后才跳到真正的start_kernel()。這個函數(shù)在init/main.c里是整個內核在架構無關層面上的總裝配線做的事包括設置啟動 CPU 狀態(tài)、解析架構相關的硬件信息、初始化內存管理、初始化中斷和時鐘、打開控制臺從這里開始printk才有輸出、初始化虛擬文件系統(tǒng)緩存、掛載最初的proc和sysfs骨架。所有這些跑完之后它做的最后一件事是調用rest_init()。這一刻進程號段 0、1、2 的分配正式拉開序幕。順帶提一句內核啟動參數(shù)的傳遞路徑GRUB 里linux那行后面跟的參數(shù)會被內核的unknown_bootoption()收集起來其中init、rdinit、initcall_debug、panic這些會被單獨識別并落到對應變量里。這就給后面定制啟動流程留了口子。2.2 rest_init 里的三段關鍵代碼決定了 0/1/2 的誕生順序rest_init()加注釋也就二三十行但每一段都值得逐句看。按現(xiàn)代 6.x 內核的寫法主干大致是這樣noinline void __ref __noreturn rest_init(void) { struct task_struct *tsk; int pid; rcu_scheduler_starting(); pid user_mode_thread(kernel_init, NULL, CLONE_FS); rcu_read_lock(); tsk find_task_by_pid_ns(pid, init_pid_ns); tsk-flags | PF_NO_SETAFFINITY; set_cpus_allowed_ptr(tsk, cpumask_of(smp_processor_id())); rcu_read_unlock(); numa_default_policy(); pid kernel_thread(kthreadd, NULL, NULL, CLONE_FS | CLONE_FILES); rcu_read_lock(); kthreadd_task find_task_by_pid_ns(pid, init_pid_ns); rcu_read_unlock(); system_state SYSTEM_SCHEDULING; complete(kthreadd_done); schedule_preempt_disabled(); cpu_startup_entry(CPUHP_ONLINE); }第一段創(chuàng)建kernel_init它拿到PID 1。注意這里用的是user_mode_thread較新內核引入早期版本就是kernel_thread差別在于前者會為新線程準備好一套能順利切到用戶態(tài)的上下文比如合適的信號處理和 TLS 狀態(tài)。緊接著的PF_NO_SETAFFINITY加set_cpus_allowed_ptr組合是把 init 死死釘在啟動 CPU 上——因為此時sched_init_smp()還沒跑跨核遷移的邏輯不可靠讓 init 亂跑會出問題。這是一個典型的啟動早期只能串行、不能并行的約束。第二段創(chuàng)建kthreadd它拿到PID 2。PID 號的分配是單調遞增的中間沒有任何其他alloc_pid()調用插隊所以 2 號這個位置非常穩(wěn)定。創(chuàng)建完立刻把返回的任務結構指針存到全局變量kthreadd_task里后面所有kthread_create()都是靠這個指針對著它發(fā)喚醒。第三段是收尾。system_state SYSTEM_SCHEDULING標記調度器可用complete(kthreadd_done)解開 PID 1 那邊的等待然后調用schedule_preempt_disabled()主動讓出一次 CPU。這次讓出的結果很關鍵當前執(zhí)行流從正在跑 start_kernel 的上下文正式降格為 idle 線程也就是 PID 0之后它進入cpu_startup_entry(CPUHP_ONLINE)在do_idle()里循環(huán)等待。所以整個過程用一句話概括start_kernel()親手創(chuàng)建了 1 號和 2 號然后自己變成了 0 號。0 號是父但它是最后一個確定身份的這個時間上的微妙之處是很多人理解錯的地方——他們會以為內核先有 0 再有 1實際上代碼順序是先 fork 出 1 和 2最后才落地成 0。注意fork_idle()給其他 CPU 創(chuàng)建 idle 線程是在kernel_init里通過smp_init()觸發(fā)的那已經是 1 號進程的工作了。也就是說0 號進程創(chuàng)建了 1 號1 號又為自己造了一堆兄弟 0 號這個循環(huán)關系挺有意思畫進程樹的時候會看到多個swapper/N。2.3 kernel_init 的長跑從內核線程到 execve 用戶程序PID 1 拿到號碼之后并不輕松它要干完一大堆初始化才能去執(zhí)行用戶程序。它在kernel_init()里做的第一件事是等wait_for_completion(kthreadd_done)確認 2 號就位。然后進入kernel_init_freeable()這是初始化工作的主戰(zhàn)場。這一大段里有幾個關鍵動作值得單拎出來smp_prepare_cpus()和smp_init()把其他 CPU 拉起來。每個核起來的過程中都會調fork_idle()造一個 idle 線程這就是swapper/1、swapper/2的來源。workqueue_init()初始化工作隊列。內核里大量異步任務靠工作隊列干活而工作隊列自己也是靠內核線程驅動的所以它得等kthreadd就緒才能跑。do_basic_setup()這里面會依次跑完各級initcall也就是驅動和子系統(tǒng)的初始化函數(shù)。你在dmesg里看到的網卡探測到磁盤識別到基本都是這一階段打出來的。打開/dev/console內核通過ksys_open(/dev/console, O_RDWR, 0)把標準輸入輸出接到控制臺然后用兩次ksys_dup(0)把 fd 1 和 fd 2 也指向它。這一步失敗會打一行Warning: unable to open an initial console.是個值得留意的排障線索。光有日志還不夠直接看代碼順序更直觀。下面是這個環(huán)節(jié)的骨架static noinline void __init kernel_init_freeable(void) { gfp_allowed_mask __GFP_BITS_MASK; set_mems_allowed(node_states[N_MEMORY]); smp_prepare_cpus(setup_max_cpus); workqueue_init(); do_pre_smp_initcalls(); smp_init(); sched_init_smp(); do_basic_setup(); if (ksys_open((const char __user *) /dev/console, O_RDWR, 0) 0) pr_err(Warning: unable to open an initial console.\n); (void) ksys_dup(0); (void) ksys_dup(0); if (!ramdisk_execute_command) ramdisk_execute_command /init; /* ... */ }初始化做完了kernel_init()就要去執(zhí)行用戶態(tài)程序了。它會按一個明確的優(yōu)先級順序嘗試一串路徑rdinit指定的程序默認是/initinit內核參數(shù)指定的程序/sbin/init/etc/init/bin/init/bin/sh只要其中一個能成功execvePID 1 就切換成了用戶態(tài)程序后面的全部跳過。如果全試一遍都失敗內核會打出一行非常經典的報錯然后 panicKernel panic - not syncing: No working init found. Try passing init option to kernel.這句幾乎每個做過嵌入式或者救援修復的人都見過。遇到它基本可以斷定根文件系統(tǒng)掛錯了、init 二進制被刪了、或者動態(tài)鏈接庫缺失導致execve返回ENOENT。一個小技巧是先用init/bin/sh啟動進去之后手工排查比對著黑屏猜要高效得多。這里有個細節(jié)容易被忽略run_init_process()內部調的是kernel_execve()是 exec 不是 fork。所以 PID 1 從內核線程變成用戶態(tài)進程的過程中號碼一直沒變。如果當初寫的是 fork 加 exec那用戶態(tài)的 init 就會是 3 號或者更大整個系統(tǒng)的進程號約定就亂了。2.4 initramfs 與 switch_rootPID 1 號碼為什么始終不變現(xiàn)在幾乎沒有發(fā)行版會直接從物理根文件系統(tǒng)啟動中間都夾了一層initramfs。原因是內核要知道怎么訪問真正的根設備得先有對應的驅動——比如 LVM、軟 RAID、磁盤加密、NVMe 控制器——而這些驅動往往以模塊形式存在模塊又躺在根文件系統(tǒng)上雞生蛋的問題就來了。initramfs就是用來打破這個死循環(huán)的它是一個由cpio打包、被內核解壓到rootfs一個tmpfs里的小型根文件系統(tǒng)包含必要的驅動模塊和一套腳本。所以真實流程是兩段第一段內核把initramfs解開掛到臨時的rootfs上PID 1 執(zhí)行里面的/init由dracut或initramfs-tools生成。這個/init是個 shell 腳本負責加載模塊、掃描磁盤、激活 LVM 和加密卷、找到真正的根設備并掛載到/sysroot之類的臨時掛載點最后執(zhí)行switch_root。第二段switch_root做的事情是把當前根目錄切換成新掛載的那個真實根文件系統(tǒng)刪掉舊的tmpfs內容騰出內存然后exec真實根上的 init 程序。同樣地這里也是 exec 而不是 fork所以 PID 1 從頭到尾沒有換過號碼。一個直接的驗證方式是看/proc/1/status里的Pid從 initramfs 階段到系統(tǒng)完全啟動這個數(shù)字一直是 1變的只是comm字段先是init后來變成systemd。如果你想看看實際的 initramfs 里都有什么可以這樣操作lsinitrd /boot/initramfs-$(uname -r).img | head -40 # RHEL/CentOS/Fedora lsinitramfs /boot/initrd.img-$(uname -r) | head -40 # Debian/Ubuntu手工解開一份出來讀/init腳本是理解啟動流程最快的路徑之一。我第一次這么干的時候才發(fā)現(xiàn)里面處理加密卷、處理多路徑設備的邏輯比想象中復雜得多也理解了不少啟動卡住的現(xiàn)場到底卡在哪個環(huán)節(jié)。3. 上手驗證把 PID 0/1/2 的痕跡一條條挖出來3.1 用 /proc 里的 PPid 字段反推父子關系理論講完接下來動手。/proc/pid/status里的PPid字段是驗證父子關系最直接的入口因為它是內核從任務結構里直接讀出來的沒法被用戶態(tài)偽造除非進程主動通過prctl之類的接口改但 PID 1 和 2 不會。grep -E ^(Name|Pid|PPid|Uid) /proc/1/status /proc/2/status正常輸出大致是/proc/1/status:Name: systemd /proc/1/status:Pid: 1 /proc/1/status:PPid: 0 /proc/2/status:Name: kthreadd /proc/2/status:Pid: 2 /proc/2/status:PPid: 0看到PPid: 0就對了。接著可以順手確認一下所有內核線程的父進程都是 2ps -eo pid,ppid,comm | awk $2 2 | head -20ps的comm列對內核線程會顯示成[kthreadd]、[ksoftirqd/0]、[kworker/0:0]這種帶方括號的形式方括號是ps用來標記這個進程沒有用戶空間命令行的約定。想驗證這一點直接讀它的cmdlinecat /proc/2/cmdline | wc -c # 輸出 0 readlink /proc/2/exe # 報錯No such file or directory兩個命令的結果都印證了同一個事實內核線程沒有用戶態(tài)可執(zhí)行文件自然也就沒有可執(zhí)行的命令行。反過來看 PID 1cat /proc/1/cmdline | tr \0 ; echo readlink -f /proc/1/exe第一個命令一般會輸出/sbin/init或者/usr/lib/systemd/systemd第二個會給出實際二進制路徑。如果這里讀出來的是別的東西那這臺機器就值得查了。3.2 pstree 與 ps 配合看清 kthreadd 的整個家族看單點不如看全貌。pstree是展示進程父子關系最順手的工具加-p參數(shù)把 PID 帶上pstree -p 1 | head -30 pstree -p 2 | head -40第一條命令看的是用戶態(tài)那棵樹systemd下面掛著systemd-journald、systemd-udevd、dbus-daemon、sshd等等這些是典型的用戶態(tài)服務。第二條命令看的是內核線程那棵樹kthreadd下面掛著一大堆方括號名字每個都是內核某個子系統(tǒng)的后臺工作者。對內核線程做分類整理挺有用我平時習慣用這條ps -eo pid,ppid,comm | awk $2 2 {print $3} | sort | uniq -c | sort -rn | head -20輸出會告訴你哪些內核線程被創(chuàng)建得最多。一般kworker數(shù)量最多因為工作隊列按 CPU、按類型普通、高優(yōu)先級、內存回收等各開一條線程核數(shù)一多線程數(shù)就上去了。這個數(shù)字本身還是個體檢指標如果kworker數(shù)量異常多可能存在阻塞型驅動或者頻繁觸發(fā)的定時任務。再補一條看線程和進程區(qū)別的命令。ps -eLf會把線程也展開同一個進程的多個線程 PID 相同但 LWP 不同ps -eLf | head -20內核線程其實是只有一個線程的進程的特例它們共享內核頁表沒有獨立用戶地址空間。3.3 觀測啟動耗時定位 init 階段的慢點知道 PID 1 是誰之后自然會想知道它啟動花了多久、慢在哪里。systemd-analyze家族是最方便的入口systemd-analyze systemd-analyze blame | head -20 systemd-analyze critical-chain第一條給出內核階段和用戶空間階段各自的耗時第二條按耗時從長到短列出各個 unit第三條畫出關鍵依賴鏈。三者配合能從不同角度定位啟動慢的原因。不過systemd-analyze的前提是系統(tǒng)用systemd當 PID 1。如果是嵌入式環(huán)境或者容器鏡像里用的是busybox init就得換個思路——加內核參數(shù)initcall_debuglinux /vmlinuz root/dev/sda2 initcall_debug ignore_loglevel重啟后dmesg里會為每個initcall輸出一行帶耗時的記錄類似calling ahci_pci_driver_init0x0/0x1b 1 initcall ahci_pci_driver_init0x0/0x1b returned 0 after 12736 usecs把所有行抓出來按耗時排序就能看出哪個驅動拖了后腿dmesg | grep initcall.*returned | sed s/.*returned // | sort -rn | head -20這套方法在排查嵌入式設備開機十幾秒的問題上非常好使。常見的結果是某個存儲控制器驅動在做復位等待或者某個網絡驅動在等 PHY 鏈路單點就可能占掉幾秒。3.4 容器環(huán)境下的 PID namespace那個假 PID 1容器里ps看到 1 號進程是應用自身的進程很多人在這個場景下會產生困惑——難道容器把宿主機的 init 換了沒有這是PID 命名空間的效果。PID 命名空間讓一組進程看到一套獨立的 PID 編號。容器啟動時runc之類的運行時把應用進程放進新的命名空間這個進程在容器內部看來是 1 號但在宿主機上分配的還是一個普通的、可能幾千號的大數(shù)字。你可以這樣驗證# 在容器外 docker inspect --format {{.State.Pid}} 容器名 # 在容器內 cat /proc/1/status | grep -E Pid|NSpid容器內的NSpid字段會同時列出兩套編號比如NSpid: 1234 1前面那個是宿主機視角的 PID后面那個是容器內視角的 PID。這個字段在排查容器進程和宿主機監(jiān)控對應關系的時候特別有用——宿主機上top看到的某個高 CPU 進程通過NSpid就能對應回具體是哪個容器里的哪個服務。還有個必須注意的坑容器里的 1 號進程只是命名空間內的 init不具備全局 init 的特殊保護。全局 init 有SIGNAL_UNKILLABLE標志內核會攔掉大部分發(fā)給它的信號容器 init 沒有這個待遇除非用--init配了 tini 或者顯式注冊了信號處理。這直接導致了下一章要講的那些容器一啟動就退出的經典問題。4. 圍繞這三個 PID 的高頻故障與排查套路4.1 PID 1 退出意味著什么以及如何避免全局 PID 1 一旦退出內核會立刻 panic報錯信息是Kernel panic - not syncing: Attempted to kill init! exitcode0x00000000這不是嚇唬人的措辭而是內核在do_exit()里對全局 init做的硬性判定。邏輯上也說得通init 是所有用戶態(tài)進程的祖先它沒了剩下的進程全成了孤兒系統(tǒng)的運行語義就崩了與其處于不確定狀態(tài)不如直接停住。但要注意內核攔的是全局 init。在 PID 命名空間內的 init 退出不會觸發(fā) panic只會讓這個命名空間里的進程收到SIGKILL然后一起死掉——容器退出的機制就是這個。所以排障時要先分清是哪種場景init 退出后的表現(xiàn)排查方向宿主機 / 物理機內核 panic屏幕卡死檢查/sbin/init是否損壞、根文件系統(tǒng)是否只讀、關鍵庫是否缺失容器pid namespace容器退出退出碼通常為 137 或 init 進程的退出碼檢查容器主進程是否正常 daemon 化、信號是否正確轉發(fā)initramfs 階段打印No working init found后 panic檢查rdinit/init參數(shù)、initramfs 是否完整容器場景下最常見的兩個坑第一把服務做成啟動后自己 fork 到后臺然后父進程退出父進程一退PID 1 沒了容器直接結束第二只寫了CMD /app/start.sh腳本里沒做exec導致 PID 1 是 shell 而不是應用腳本收到SIGTERM后不會轉發(fā)給子進程docker stop要等超時才被殺。正確做法是在腳本最后一行用exec /app/server讓應用直接接管 PID 1。4.2 僵尸、孤兒與信號回收的坑父子關系帶來的另一個麻煩是進程回收。子進程退出后內核不會馬上把它的任務結構釋放掉得等父進程調用wait()或waitpid()來讀取退出狀態(tài)否則它就變成僵尸Z狀態(tài)占著 PID 號和一小塊內核內存不放。那如果父進程先死了呢剩下的子進程就成了孤兒內核會通過find_new_reaper()給它們找一個新爸爸。默認規(guī)則是往上找最終落到全局 initPID 1頭上。所以你在服務器上看到一堆PPid是 1 的進程很多時候它們原本是有爹的爹死了才被 init 收養(yǎng)。這條規(guī)則現(xiàn)在有了例外。Linux 支持PR_SET_CHILD_SUBREAPER這個 prctl 標志某個進程可以聲明自己愿意當中間層收養(yǎng)者。systemd就是這么干的——它給每個用戶會話設了 subreaper這樣會話里的孤兒進程會被會話級的管理進程收走而不是全部涌向 PID 1。這個設計的實際意義在于面向用戶的進程可以拿到更準確的退出通知也避免 PID 1 被大量收養(yǎng)和回收請求淹沒。排查孤兒和僵尸的常用組合ps -eo pid,ppid,stat,comm | awk $3 ~ /^Z/ ps -eo pid,ppid,stat,comm | awk $2 1 $3 !~ /^Z/ | head -20第一條找僵尸第二條找被 init 收養(yǎng)的孤兒。如果僵尸數(shù)量持續(xù)增長說明有父進程從來不回收子進程這時候要么修代碼要么給它設個 subreaper 兜住如果孤兒數(shù)量異常多往往意味著有服務在反復 fork 并崩潰。提示寫自動化腳本的時候subprocess.Popen之后一定要配對wait()或communicate()否則在長時間運行的服務里僵尸會一點點累積最后把進程表塞滿。4.3 PID 耗盡與 pid_max 的調整邊界PID 是有限的。上限由/proc/sys/kernel/pid_max決定32 位系統(tǒng)上默認 3276864 位系統(tǒng)上默認也是 32768但可以調到 4194304。查看和調整cat /proc/sys/kernel/pid_max sysctl -w kernel.pid_max4194304調大之后有個副作用如果同時開著kernel.pid_max和kernel.threads-max的監(jiān)控會發(fā)現(xiàn)內核用于索引 PID 的 IDR 結構變大占用的內存會略有增加但通常可以忽略。更需要注意的是不要在有大量短生命周期任務、又用了 IPsec 或者某些依賴高位 PID 的老代碼的系統(tǒng)上亂調歷史上有過因為 PID 超過某個閾值導致兼容性問題的案例。PID 耗盡的典型報錯是-bash: fork: retry: Resource temporarily unavailable看到它先別急著調pid_max。真正的根因可能是這幾種某進程在瘋狂 fork比如 shell 循環(huán)出 bug、爬蟲并發(fā)失控、cron 里的腳本沒有互斥、僵尸進程堆積占號、ulimit -u設得太低限制了單用戶進程數(shù)。按這個順序排查ps -eo pid,user,comm | awk {print $2} | sort | uniq -c | sort -rn | head ps -eo stat | grep -c ^Z ulimit -u第一條看哪個用戶在占號第二條數(shù)僵尸第三條看用戶級限制。定位到源頭再去改參數(shù)比盲目調大上限靠譜得多。4.4 常見疑問速查表含 PID 名稱歧義說明圍繞這三個編號我被問過的問題重復率很高干脆整理成表疑問結論驗證方式/proc/0為什么不存在PID 0 未經過alloc_pid()不在命名空間哈希表里ls /proc | sort -n | headps為什么看不到 0 號沒有/proc目錄項ps數(shù)據(jù)源就是/procps -eo pid | sort -n | head每個 CPU 的 idle 線程 PID 是幾都是 0命令名swapper/Ncat /proc/sched_debug | grep -i swapperkthreadd一定是 2 號嗎現(xiàn)代內核中穩(wěn)定是 2因為 PID 分配單調遞增且中間無插入grep PPid /proc/2/status為什么內核線程父進程是 2所有kthread_create()請求都由kthreadd落地ps -eo pid,ppid,comm | awk $22收到kill -9 1會怎樣全局 init 有SIGNAL_UNKILLABLE保護信號被忽略在測試機上用非 root 試觀察返回容器里的 PID 1 是宿主機的嗎不是是 PID 命名空間內的獨立編號grep NSpid /proc/1/status怎么確認當前 init 是哪個程序讀/proc/1/exe和/proc/1/commreadlink -f /proc/1/exe最后補一個容易造成搜索混淆的點操作系統(tǒng)里的 PID 是 Process ID自動化控制里的 PID 是 Proportional-Integral-Derivative。這兩者除了縮寫一樣毫無關系。你在搜索引擎里搜pid 算法、位置式 pid、增量式 pid、pid 控制器出來的全是控制理論內容講的是用比例、積分、微分三項去擬合誤差曲線用在電機調速、溫度控制、無人機姿態(tài)穩(wěn)定上。而搜linux pid、進程 pid、ppid才是操作系統(tǒng)這一側。寫技術文檔的時候最好把全稱寫清楚不然讀者很容易被帶偏我自己就曾經在一個內部 wiki 里把兩邊的鏈接混著貼過后來被同事吐槽了很久。5. 把這些知識落到實際工作里5.1 定制最小 init 與內核啟動參數(shù)理解了 PID 1 的選取順序就能反過來控制啟動行為。最常用的兩個參數(shù)是init和rdinit它們的優(yōu)先級不一樣rdinit只對 initramfs 里的/init生效如果設了它內核會優(yōu)先嘗試這個路徑init會在 initramfs 交接完之后在真實根文件系統(tǒng)上執(zhí)行兩者都不給的時候內核按/sbin/init、/etc/init、/bin/init、/bin/sh的順序試。在 GRUB 里臨時加參數(shù)很簡單選中啟動項按e找到linux那行末尾追加CtrlX啟動。做救援的時候我最常用的組合是init/bin/bash rw它能讓你在幾乎沒有任何服務啟動的情況下拿到一個 root shell用來改密碼、修配置文件、檢查磁盤。需要注意的是這種方式進來之后沒有systemd幫忙掛載文件系統(tǒng)/proc、/sys可能是空的得手工掛mount -t proc proc /proc mount -t sysfs sysfs /sys如果是做嵌入式產品把 PID 1 換成一個自己寫的極簡程序也很常見。核心要求只有幾條永遠不要退出、正確回收孤兒進程循環(huán)waitpid(-1, ...)、把收到的信號轉發(fā)給子進程、在收到SIGTERM時有序關停。這幾十行代碼寫好了整個系統(tǒng)的最小化就能再往前推一步。5.2 用 PID 樹排查資源異常與可疑進程線上出問題的時候進程樹往往是第一手線索。CPU 或者內存突然飆高先做這三步top -o %CPU -b -n 1 | head -20 ps -eo pid,ppid,%cpu,%mem,comm --sort-%cpu | head -20 pstree -p 可疑PID前兩條定位到具體進程第三條把它放回進程樹里看。很多時候單個進程看起來人畜無害但往上追兩層會發(fā)現(xiàn)它是一個失控腳本的孫子進程或者是某個已經崩潰但沒退出的服務殘留。這種順藤摸瓜的排查方式比盯著單個進程看有效得多。還有一類場景是排查可疑進程。判斷依據(jù)可以是進程的可執(zhí)行文件路徑指向/tmp或者/dev/shm正常服務不會放這兒、PPid是 1 但找不到對應的 systemd unit、進程名的拼寫和正常系統(tǒng)進程只差一兩個字符、/proc/pid/exe指向的文件已被刪除readlink會帶(deleted)后綴。這幾條組合起來看基本能篩出絕大多數(shù)異常。ls -l /proc/*/exe 2/dev/null | grep deleted systemctl status $(cat /proc/pid/comm)5.3 容器 init 與 subreaper 的取舍建議容器場景下要不要加一個 init 進程一直有爭議。我的建議是按應用類型分如果容器里跑的是單一前臺進程并且它自己正確處理了SIGTERM、自己wait了子進程那就沒必要加。多一層反而增加信號轉發(fā)的復雜度和調試成本。前提是CMD用的是 exec 形式不要讓 shell 擋在前面。如果應用會產生后臺子進程、或者會在運行中 fork 出短命進程比如調用外部命令做一次任務強烈建議加。用docker run --init或者 compose 里寫init: trueDocker 會注入一個極小的 init。它干的事就是回收僵尸、轉發(fā)信號正好補上應用自己懶得做的那部分。如果容器是給開發(fā)人員用的交互環(huán)境比如一個基礎的開發(fā)鏡像那就更應該加否則 shell 里隨手起的后臺進程會一直堆著。這里有個容易踩的細節(jié)加了--init之后容器內的 PID 1 就不再是應用本身而是那個小 init應用的 PID 變成 2。這時候如果應用邏輯里有硬編碼我是 1 號的判斷例如判斷收到某個信號時該怎么處理行為會變。線上切之前最好先在測試環(huán)境驗證一遍信號路徑?；仡^看這一整條鏈路從rest_init()里的兩次kernel_thread()到kernel_init一路做完initcall再execve成systemd再到kthreadd默默孵化出幾百個內核線程這三個編號其實各管一攤0 號是數(shù)據(jù)和調度的地基1 號是用戶世界的入口2 號是內核后臺的車間。我在實際調試中養(yǎng)成了一個習慣拿到一臺不熟悉的機器先敲三條命令——grep PPid /proc/1/status、ps -eo pid,ppid,comm | awk $22 | wc -l、readlink -f /proc/1/exe。第一條確認父子關系沒被改過第二條大致知道內核線程規(guī)模第三條確認 init 是什么。三秒鐘就能對這臺機器的啟動形態(tài)有個基本判斷比翻配置文件快得多。