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