程實戰(zhàn)：從fork、僵尸進(jìn)程到多進(jìn)程通信)
做嵌入式Linux開發(fā)繞不開進(jìn)程。我剛開始接觸嵌入式Linux應(yīng)用層時總覺得進(jìn)程這玩意不就是幾個API嗎fork一下、exec一下死記硬背就完事。但真到項目里被僵尸進(jìn)程、資源競爭、IPC選型這些破事折磨過幾輪之后才明白進(jìn)程是理解整個Linux應(yīng)用開發(fā)的基石地基沒打牢上層寫再多業(yè)務(wù)代碼都是空中樓閣。這篇博文就圍繞嵌入式場景下的進(jìn)程實戰(zhàn)來寫從核心概念、生命周期、創(chuàng)建方式、回收治理到進(jìn)程間通信和典型的多進(jìn)程項目實操全部按我實際做過的項目和踩過的坑來展開。適合剛?cè)腴T嵌入式Linux應(yīng)用開發(fā)的同學(xué)也適合那些會調(diào)API但對進(jìn)程底層行為理解不透、想在項目里少踩坑的開發(fā)者。1. 為什么嵌入式Linux應(yīng)用開發(fā)要學(xué)透進(jìn)程1.1 進(jìn)程在嵌入式系統(tǒng)里的位置先看一個現(xiàn)實問題MCU裸機開發(fā)時代整個系統(tǒng)就一個死循環(huán)在跑所有功能都是輪詢中斷代碼寫起來簡單直接。但上了嵌入式Linux動不動就是幾百萬行代碼多個功能模塊要同時跑還要保證某個模塊掛掉不影響整體系統(tǒng)。這時候進(jìn)程就是最基本的隔離單元——每個進(jìn)程有獨立的地址空間、獨立的資源一個進(jìn)程崩潰了內(nèi)核會回收它的資源其他進(jìn)程該干嘛繼續(xù)干嘛。我在一個車載信息終端的項目里遇到過這種情況顯示模塊需要常駐運行但負(fù)責(zé)數(shù)據(jù)上報的網(wǎng)絡(luò)模塊時不時會因為運營商網(wǎng)絡(luò)異常而卡死。如果所有邏輯都在一個進(jìn)程里網(wǎng)絡(luò)模塊一卡整個屏幕就跟著假死。后來把顯示、網(wǎng)絡(luò)上報、外設(shè)監(jiān)控拆成三個獨立進(jìn)程網(wǎng)絡(luò)模塊掛了看門狗自動拉起它顯示模塊完全不受影響。這就是進(jìn)程隔離在嵌入式系統(tǒng)里最典型、也是最核心的作用。還有一點容易被忽略Linux內(nèi)核的進(jìn)程調(diào)度器本身就是為多任務(wù)場景設(shè)計的。嵌入式Linux不是讓你像裸機那樣自己寫調(diào)度器而是讓你站在進(jìn)程這個抽象層上做產(chǎn)品設(shè)計。你只需要關(guān)心這個模塊放哪個進(jìn)程里、進(jìn)程之間怎么通信剩下的CPU調(diào)度、時間片分配、優(yōu)先級搶占內(nèi)核全都幫你處理好了。1.2 進(jìn)程與線程的選擇邏輯很多新手上來就糾結(jié)到底用多進(jìn)程還是多線程我在團隊里帶新人時給過一個可以快速落地的判斷標(biāo)準(zhǔn)模塊之間需要強隔離、需要獨立崩潰恢復(fù)能力的選進(jìn)程。模塊之間需要頻繁、大量、低延遲地共享數(shù)據(jù)性能要求極高的選線程。嵌入式系統(tǒng)內(nèi)存非常吃緊比如總內(nèi)存只有64MB進(jìn)程數(shù)量要克制優(yōu)先用線程。安全等級要求高某個模塊不能被其他模塊拖垮必須用進(jìn)程隔離。從開發(fā)成本來說進(jìn)程間通信比線程間共享內(nèi)存要繁瑣寫起來多不少樣板代碼。但進(jìn)程帶來的穩(wěn)定性收益在嵌入式這種無人值守、連續(xù)運行幾個月不重啟的場景里是非常值得的。我個人的原則是能用進(jìn)程解決穩(wěn)定性問題的就別省這個成本省下的調(diào)試時間遠(yuǎn)超多寫的那些代碼。2. 進(jìn)程的核心概念與生命周期2.1 PID與進(jìn)程描述符進(jìn)程在Linux里有唯一的身份標(biāo)識就是PIDProcess ID。PID是int類型從1開始遞增分配達(dá)到上限后會回繞同時為了避免pid重用得太快引發(fā)安全問題內(nèi)核會有pid_max之類的限制。嵌入式的產(chǎn)品里PID一般不會有什么問題但了解這個機制能幫你理解為什么某些系統(tǒng)工具會顯示PID很大。比PID更底層的概念是進(jìn)程描述符也就是內(nèi)核里的task_struct結(jié)構(gòu)體。它包含了進(jìn)程的所有信息PID、PPID父進(jìn)程PID、狀態(tài)、優(yōu)先級、打開的文件描述符表、內(nèi)存地址空間描述、信號處理函數(shù)指針、各種計時器和統(tǒng)計信息。你可以這樣理解task_struct就是進(jìn)程在內(nèi)核里的檔案袋所有跟進(jìn)程相關(guān)的東西都裝在里面。在嵌入式應(yīng)用層開發(fā)時常用這幾個接口獲取進(jìn)程信息#include unistd.h #include sys/types.h pid_t getpid(void); // 獲取當(dāng)前進(jìn)程PID pid_t getppid(void); // 獲取父進(jìn)程PID查看系統(tǒng)進(jìn)程狀態(tài)用ps命令就夠ps -ef ps -aux嵌入式系統(tǒng)如果busybox裁剪過可能沒有完整ps但通常會有簡化版的ps用法類似。2.2 進(jìn)程狀態(tài)機與狀態(tài)切換進(jìn)程在生命周期里不是一直運行的它會在這幾個狀態(tài)之間切換RTASK_RUNNING可執(zhí)行狀態(tài)。注意這個狀態(tài)包含兩種情況——正在CPU上運行或者排在就緒隊列里等待被調(diào)度。也就是說R不代表正在跑它只代表隨時可以跑。STASK_INTERRUPTIBLE可中斷睡眠。進(jìn)程在等待某個條件滿足比如等鍵盤輸入、等socket數(shù)據(jù)可以被信號喚醒。這是嵌入式進(jìn)程最常見的狀態(tài)大量時間都耗在這里。DTASK_UNINTERRUPTIBLE不可中斷睡眠。一般在等待磁盤IO等內(nèi)核操作完成不能響應(yīng)信號。如果系統(tǒng)里有大量D狀態(tài)進(jìn)程且長時間不退出去通常是IO子系統(tǒng)出了問題要留意。TTASK_STOPPED停止?fàn)顟B(tài)。通過SIGSTOP信號進(jìn)入SIGCONT恢復(fù)。ZTASK_ZOMBIE僵尸狀態(tài)。進(jìn)程已經(jīng)退出但資源還沒有被父進(jìn)程回收。嵌入式開發(fā)里最常打交道的就是僵尸狀態(tài)這個問題我放到后面專門說。你只要記住一句口訣Z狀態(tài)的進(jìn)程已經(jīng)死了它的靈魂task_struct還在內(nèi)核里飄著等父進(jìn)程來收尸。2.3 進(jìn)程、線程、程序的區(qū)別這三個詞經(jīng)常被混用但差別很關(guān)鍵程序是靜態(tài)的就是磁盤上的一個ELF文件躺著不動。進(jìn)程是程序跑起來之后的動態(tài)實體有自己的地址空間、文件描述符、信號處理等一堆運行時資源。線程是進(jìn)程內(nèi)部的執(zhí)行單元同一個進(jìn)程里的多個線程共享地址空間和大部分資源各自有獨立的棧和寄存器上下文。用生活場景打個比方程序是一本菜譜進(jìn)程是照著菜譜在廚房里做菜的這個操作過程線程則是操作過程里掌勺、切菜、配菜這些同時進(jìn)行的動作。菜譜可以復(fù)制很多份就像同一個程序可以跑出多個進(jìn)程比如系統(tǒng)里開了好幾個相同名稱的shell一個廚房里可以多個人協(xié)作就像進(jìn)程里可以開多個線程。在嵌入式Linux里線程的實現(xiàn)是NPTLNative POSIX Thread Library本質(zhì)上是基于clone系統(tǒng)調(diào)用來創(chuàng)建的clone和fork共享了很多底層機制。理解這一點很重要線程并不是什么神秘的東西它就是共享了地址空間等資源的進(jìn)程變體。3. 進(jìn)程創(chuàng)建的三種姿勢與原理3.1 fork系統(tǒng)調(diào)用的行為與寫時拷貝創(chuàng)建進(jìn)程最經(jīng)典的方式就是fork。新手理解fork最繞的一個點就是fork調(diào)用一次返回兩次。父進(jìn)程里返回子進(jìn)程的PID大于0子進(jìn)程里返回0失敗返回-1。你用返回值區(qū)分父子身份然后讓父子進(jìn)程走不同的代碼分支。先看最基本的代碼#include stdio.h #include unistd.h #include sys/types.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork error); return -1; } else if (pid 0) { printf(child process, pid%d, ppid%d\n, getpid(), getppid()); } else { printf(parent process, pid%d, child pid%d\n, getpid(), pid); } return 0; }編譯運行之后你會發(fā)現(xiàn)一個有意思的現(xiàn)象兩個printf的輸出順序不一定固定父子進(jìn)程誰先跑完全由內(nèi)核調(diào)度器決定。這也是多進(jìn)程編程和裸機順序執(zhí)行思維最大的差異點——從fork返回那一刻起兩個執(zhí)行流就是并發(fā)的、不確定的。fork背后有一個極其重要的機制叫寫時拷貝Copy-On-WriteCOW。傳統(tǒng)的fork會立刻把父進(jìn)程整個地址空間復(fù)制一份給子進(jìn)程成本極高。所以現(xiàn)代Linux內(nèi)核在fork時不真正拷貝物理內(nèi)存而是把父子進(jìn)程的頁表都指向同一塊物理內(nèi)存并把這些頁標(biāo)記成只讀。如果父子進(jìn)程誰也沒改數(shù)據(jù)就一直共享這塊內(nèi)存一旦某個進(jìn)程要寫某個頁內(nèi)核才會觸發(fā)缺頁異常真正拷貝一份出來讓寫操作的進(jìn)程擁有自己的副本。這個機制在嵌入式環(huán)境里意義很大雖然我們有soc內(nèi)存動輒幾百MB甚至上GB但系統(tǒng)內(nèi)存依然寶貴COW讓fork的啟動成本變得很低。特別是在fork后馬上exec執(zhí)行新程序這種典型場景里COW保證了中間幾乎零拷貝。3.2 vfork與exec族的搭配使用vfork是fork的老前輩它的語義是創(chuàng)建子進(jìn)程掛起父進(jìn)程直到子進(jìn)程調(diào)用exec或者退出。這么做是為了避免在早期沒有MMU的Linux系統(tǒng)上復(fù)制頁表。子進(jìn)程和父進(jìn)程完全共享地址空間連棧都共享所以在vfork之后、exec之前子進(jìn)程絕對不能修改任何數(shù)據(jù)否則會搞壞父進(jìn)程的現(xiàn)場?，F(xiàn)代Linux基本上不需要用vfork了COW機制已經(jīng)完美解決了fork的性能問題。我在代碼評審里看到有人用vfork基本都是歷史習(xí)慣我會建議改成fork。有個別嵌入式場景還在用vfork純粹是為了極致地省一點fork時間但收益極小、風(fēng)險極高不推薦。exec族真正干的事情是用一個新的程序完全替換當(dāng)前進(jìn)程的代碼段、數(shù)據(jù)段、堆和棧。進(jìn)程PID不變內(nèi)核說你還是你但你已經(jīng)不是你了。exec族函數(shù)一共六個int execl(const char *path, const char *arg, ...); int execlp(const char *file, const char *arg, ...); int execle(const char *path, const char *arg, ..., char *const envp[]); int execv(const char *path, char *const argv[]); int execvp(const char *file, char *const argv[]); int execvpe(const char *file, char *const argv[], char *const envp[]);帶l的是參數(shù)列表方式帶v的是參數(shù)數(shù)組方式帶p的是會在PATH環(huán)境變量里搜索可執(zhí)行文件帶e的是可以顯式傳入環(huán)境變量。記不住就記一條在嵌入式里最常用的是execlp和execvp因為它們可以按PATH找程序省得路徑寫錯踩坑。常見的一個組合用法是fork之后在子進(jìn)程里exec#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { /* 子進(jìn)程執(zhí)行外部程序 */ execlp(ls, ls, -l, NULL); /* exec執(zhí)行成功的話到不了這里 */ perror(execlp error); _exit(1); } else if (pid 0) { wait(NULL); /* 父進(jìn)程等待子進(jìn)程結(jié)束 */ } return 0; }這里有個細(xì)節(jié)exec失敗后要調(diào)用_exit而不是exit。因為exit會刷新stdio緩沖區(qū)如果exec失敗時緩沖區(qū)里還有從父進(jìn)程繼承來的數(shù)據(jù)可能會被寫兩次。_exit直接進(jìn)入內(nèi)核退出不碰用戶態(tài)緩沖區(qū)更安全。3.3 父子進(jìn)程的資源繼承清單新手經(jīng)常會問fork之后子進(jìn)程到底繼承了父進(jìn)程的什么簡單記幾乎繼承了所有的用戶態(tài)資源。繼承的資源包括環(huán)境變量、打開的文件描述符表、當(dāng)前工作目錄、信號處理方式注意要捕獲的信號處理函數(shù)被繼承被忽略的信號設(shè)置也被繼承但未決信號不繼承、進(jìn)程組ID、會話ID、控制終端等。不繼承的東西也要記住子進(jìn)程擁有全新的PID必然不同各種鎖的狀態(tài)不繼承未決的信號不繼承計時器不繼承還有進(jìn)程的資源使用計數(shù)會清零。這里面最坑的是文件描述符繼承。如果在父進(jìn)程里打開了一個文件fork之后子進(jìn)程也持有這個文件描述符指向同一個文件描述。這會導(dǎo)致兩個進(jìn)程共享同一個文件偏移量。如果父子進(jìn)程同時往同一文件寫數(shù)據(jù)你會看到數(shù)據(jù)交錯甚至覆蓋因為共享偏移會互相影響。解決思路通常是子進(jìn)程需要讀寫文件時在子進(jìn)程里自己open一個或者fork之前別打開這個文件、fork之后各開各的。4. 子進(jìn)程回收與僵尸進(jìn)程治理4.1 wait與waitpid的阻塞和非阻塞回收子進(jìn)程退出后內(nèi)核會保留它的task_struct直到父進(jìn)程調(diào)用wait或者waitpid把它收走這個收走的過程也叫回收。如果不回收子進(jìn)程就成了僵尸進(jìn)程?；窘涌?include sys/wait.h pid_t wait(int *status); pid_t waitpid(pid_t pid, int *status, int options);wait是阻塞的只要有子進(jìn)程沒退出它就一直卡著。waitpid更靈活可以通過參數(shù)控制等待哪個子進(jìn)程、是否阻塞。waitpid的pid參數(shù)要認(rèn)真記pid 0等待指定PID的子進(jìn)程。pid -1等待任意子進(jìn)程相當(dāng)于wait。pid 0等待與當(dāng)前進(jìn)程同進(jìn)程組的任意子進(jìn)程。pid -1等待進(jìn)程組ID等于|pid|的任意子進(jìn)程。options參數(shù)至少記住兩個0阻塞等待。WNOHANG非阻塞如果沒有子進(jìn)程退出立即返回0。還有WUNTRACED子進(jìn)程停止也返回和WCONTINUED在嵌入式里用得少了解即可。status參數(shù)用來獲取子進(jìn)程的退出信息需要用宏來解析int status; pid_t ret waitpid(pid, status, WNOHANG); if (ret 0) { if (WIFEXITED(status)) { printf(normal exit, status%d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(killed by signal %d\n, WTERMSIG(status)); } }實際開發(fā)里我強烈建議統(tǒng)一用waitpid WNOHANG的模式寫子進(jìn)程回收邏輯尤其是父進(jìn)程有主循環(huán)的場景嵌入式很多進(jìn)程都長這樣while (1) { pid_t ret waitpid(-1, status, WNOHANG); if (ret 0) { /* 有子進(jìn)程退出了處理回收 */ } /* 繼續(xù)干父進(jìn)程自己的事 */ ... }這樣父進(jìn)程既不會阻塞在等子進(jìn)程上也不會漏掉任何一個子進(jìn)程退出的回收時機。4.2 僵尸進(jìn)程的產(chǎn)生與清理僵尸進(jìn)程是怎么來的子進(jìn)程先退出父進(jìn)程還沒來得及調(diào)用wait。這個還沒可以是微秒也可以是永遠(yuǎn)。如果父進(jìn)程壓根不調(diào)用wait那子進(jìn)程變成僵尸之后就永遠(yuǎn)占著一個內(nèi)核task_struct無法釋放。嵌入式系統(tǒng)里僵尸進(jìn)程的危害比其他場景更大因為嵌入式設(shè)備的資源本來就緊。一個兩個僵尸可能看不出來但如果父進(jìn)程反復(fù)創(chuàng)建子進(jìn)程又不管僵尸越積越多最終會導(dǎo)致系統(tǒng)無法創(chuàng)建新進(jìn)程——進(jìn)程數(shù)達(dá)到上限。清理僵尸進(jìn)程有幾種辦法方法一最關(guān)鍵也最常用的在父進(jìn)程里注冊SIGCHLD信號處理函數(shù)。子進(jìn)程退出時內(nèi)核會自動給父進(jìn)程發(fā)SIGCHLD信號。父進(jìn)程在這個信號處理函數(shù)里調(diào)用waitpid回收。#include signal.h void sigchld_handler(int sig) { int status; pid_t pid; while ((pid waitpid(-1, status, WNOHANG)) 0) { /* 回收一個已退出的子進(jìn)程 */ } } int main(void) { struct sigaction sa; sa.sa_handler sigchld_handler; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; sigaction(SIGCHLD, sa, NULL); /* 正常fork子進(jìn)程 */ fork(); ... }注意信號處理函數(shù)里要用while循環(huán)把waitpid調(diào)到底因為信號可能被合并一次信號到達(dá)可能對應(yīng)多個子進(jìn)程退出只回收一個會漏。方法二子進(jìn)程還沒有孫子進(jìn)程的話可以fork之后立刻wait父子同步運行子進(jìn)程退出時父進(jìn)程馬上回收。適合簡單的父進(jìn)程調(diào)子進(jìn)程干活的場景。方法三讓子進(jìn)程被init進(jìn)程收養(yǎng)。子進(jìn)程變成孤兒后會被init接管init會自動回收孫輩的僵尸。這個思路通常用在守護(hù)進(jìn)程設(shè)計里。還有一個必須強調(diào)的坑信號處理函數(shù)里能用waitpid嗎能用但要小心。waitpid不是異步信號安全函數(shù)async-signal-safe列表里百分百安全的但waitpid本身在POSIX里有爭議實際Linux使用waitpid在信號處理函數(shù)里回收子進(jìn)程是非常普遍的實踐。更穩(wěn)妥的方式是在信號處理函數(shù)里只置一個flag然后在主循環(huán)里檢查flag再調(diào)waitpid。我在實際項目里兩種都寫過如果代碼量不大且邏輯簡單直接在handler里waitpid也沒問題如果主循環(huán)邏輯復(fù)雜、對可靠性要求高建議用flag方式。4.3 孤兒進(jìn)程與守護(hù)進(jìn)程化子進(jìn)程的父進(jìn)程先退出了子進(jìn)程就成了孤兒。孤兒不會被丟棄而是被直接過繼給init/systemd進(jìn)程通常PID為1由它負(fù)責(zé)回收。所以孤兒進(jìn)程一般不會變成僵尸。在嵌入式里我們更關(guān)心的是反過來一種場景怎么主動脫單把自己變成孤兒然后讓init收養(yǎng)自己。這就是守護(hù)進(jìn)程daemon化的核心步驟之一。一個標(biāo)準(zhǔn)的守護(hù)進(jìn)程化流程通常是調(diào)用fork父進(jìn)程退出子進(jìn)程繼續(xù)。子進(jìn)程調(diào)用setsid創(chuàng)建新的會話徹底脫離控制終端。再次fork讓新進(jìn)程不再是會話首進(jìn)程防止它重新獲取控制終端。修改當(dāng)前工作目錄到根目錄或者其他固定目錄。重定向標(biāo)準(zhǔn)輸入輸出錯誤到/dev/null或日志文件。設(shè)置文件權(quán)限掩碼umask(0)。如果你用的是glibc可以直接調(diào)用daemon(0, 0)函數(shù)一步完成上面大部分工作。但嵌入式系統(tǒng)用的庫不一定有daemon函數(shù)或者你想精細(xì)控制每一步就手寫。很多嵌入式進(jìn)程不要求完全脫離終端直接寫一個正常的一直運行的進(jìn)程配合啟動腳本用nohup或者啟動框架管理也是常見做法。守護(hù)進(jìn)程化的核心意義是進(jìn)程生命周期不再依賴終端和父進(jìn)程哪怕登錄會話關(guān)閉進(jìn)程照樣跑。5. 嵌入式場景下的進(jìn)程間通信實戰(zhàn)5.1 管道通信最直接的進(jìn)程間數(shù)據(jù)傳輸進(jìn)程間通信IPC在嵌入式Linux里是重頭戲。不同進(jìn)程有獨立地址空間無法直接訪問對方內(nèi)存必須通過內(nèi)核提供的機制來傳數(shù)據(jù)。管道是最基礎(chǔ)的一種IPC分兩種匿名管道pipe只能用于有親緣關(guān)系的進(jìn)程之間父子進(jìn)程、兄弟進(jìn)程。通過pipe()創(chuàng)建一對文件描述符fd[0]是讀端fd[1]是寫端。父進(jìn)程寫、子進(jìn)程讀的經(jīng)典流程是pipe創(chuàng)建管道fork之后寫方關(guān)閉讀端讀方關(guān)閉寫端雙方通過管道傳數(shù)據(jù)。命名管道FIFO通過mkfifo創(chuàng)建文件系統(tǒng)里有一個可見的管道文件任意兩個進(jìn)程只要打開同一個FIFO文件就能通信不需要親緣關(guān)系。嵌入式里匿名管道最常見的用途是父進(jìn)程把某個子進(jìn)程的輸出抓回來。比如父進(jìn)程啟動一個子進(jìn)程跑一個外設(shè)檢測程序然后讀它的標(biāo)準(zhǔn)輸出#include stdio.h #include unistd.h #include string.h int main(void) { int fds[2]; pipe(fds); pid_t pid fork(); if (pid 0) { /* 子進(jìn)程把標(biāo)準(zhǔn)輸出重定向到管道寫端 */ close(fds[0]); dup2(fds[1], STDOUT_FILENO); close(fds[1]); execlp(cat, cat, /proc/cpuinfo, NULL); _exit(1); } /* 父進(jìn)程從管道讀端讀取數(shù)據(jù) */ close(fds[1]); char buf[256]; ssize_t n; while ((n read(fds[0], buf, sizeof(buf))) 0) { write(STDOUT_FILENO, buf, n); } close(fds[0]); return 0; }這里dup2把子進(jìn)程的標(biāo)準(zhǔn)輸出重定向到管道寫端。管道的讀寫是阻塞式的讀端在管道沒數(shù)據(jù)時會阻塞寫端在管道緩沖區(qū)滿時會阻塞。管道緩沖區(qū)默認(rèn)大小在Linux上一般是64KB內(nèi)核版本不同有差異如果你寫的數(shù)據(jù)超過緩沖區(qū)大小且讀端沒及時讀寫進(jìn)程會卡住。所以管道適合傳小數(shù)據(jù)量、流式的數(shù)據(jù)不適合傳大塊數(shù)據(jù)。5.2 信號機制異步事件處理信號在嵌入式里主要用來處理異步事件和簡單的通知。除了前面說的SIGCHLD常見的還有SIGTERM15默認(rèn)終止進(jìn)程可被捕獲和忽略常用于優(yōu)雅關(guān)停。SIGKILL9強制終止進(jìn)程不可捕獲、不可忽略。別指望在SIGKILL里做清理。SIGINT2CtrlC觸發(fā)。SIGALRM14定時器到期觸發(fā)。注冊信號處理函數(shù)建議用sigaction而不是老的signal函數(shù)因為signal在不同Unix系統(tǒng)上語義有差異sigaction行為是POSIX標(biāo)準(zhǔn)定義的更可靠struct sigaction sa; sa.sa_handler handler_func; sigemptyset(sa.sa_mask); sa.sa_flags 0; sigaction(SIGTERM, sa, NULL);信號處理函數(shù)里能做什么事情限制非常多。理論上是只做異步信號安全的事操作變量置標(biāo)志位、write到管道/文件、調(diào)用signal相關(guān)的函數(shù)都是可以的。但malloc、printf、fprintf這類不能保證安全因為可能在主程序里正執(zhí)行到一半、信號處理函數(shù)又進(jìn)來了導(dǎo)致堆狀態(tài)錯亂。我自己寫嵌入式進(jìn)程的關(guān)停邏輯時典型做法是static volatile sig_atomic_t g_stop_flag 0; void term_handler(int sig) { g_stop_flag 1; } int main(void) { /* 注冊SIGTERM/SIGINT */ ... while (!g_stop_flag) { /* 主循環(huán)正常處理業(yè)務(wù) */ } /* 退出前做資源清理、落日志 */ return 0; }volatile sig_atomic_t是標(biāo)準(zhǔn)推薦的信號標(biāo)志類型確保讀寫是原子的、且不會被編譯器優(yōu)化到寄存器里導(dǎo)致主循環(huán)看不到變化。這個信號置標(biāo)志位 主循環(huán)輪詢的模式在嵌入式里比任何花哨的做法都穩(wěn)。5.3 System V與POSIX共享內(nèi)存選型進(jìn)程間要傳大量數(shù)據(jù)尤其像攝像頭幀數(shù)據(jù)、傳感器批量采樣數(shù)據(jù)這種用管道就不合適了性能差、還要拷貝。共享內(nèi)存是正解多個進(jìn)程把同一塊物理內(nèi)存映射到自己的地址空間讀寫數(shù)據(jù)不需要經(jīng)過內(nèi)核拷貝是性能最高的IPC方式。System V共享內(nèi)存用起來偏繁瑣shmget創(chuàng)建/獲取、shmat映射、shmdt解除映射、shmctl控制。POSIX共享內(nèi)存用起來相對優(yōu)雅shm_open創(chuàng)建、mmap映射、munmap解除、shm_unlink刪除。嵌入式Linux一般兩者都支持我推薦用POSIX接口因為它和mmap的配合更統(tǒng)一接口也更少。代碼模板大概長這樣共享端和接收端配合/* 創(chuàng)建端 */ #include sys/mman.h #include fcntl.h #include unistd.h int shm_fd shm_open(/my_shm, O_CREAT | O_RDWR, 0666); ftruncate(shm_fd, 4096); void *addr mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0); /* 寫數(shù)據(jù)到addr指向的內(nèi)存 *//* 接收端 */ int shm_fd shm_open(/my_shm, O_RDWR, 0666); void *addr mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0); /* 從addr讀取數(shù)據(jù) */共享內(nèi)存的坑在于同步。多個進(jìn)程同時寫同一塊共享內(nèi)存必須配合信號量來保證互斥。System V信號量或者POSIX信號量都能干這事嵌入式里我常用POSIX有名信號量因為接口簡單、跨進(jìn)程好用#include semaphore.h sem_t *sem sem_open(/my_sem, O_CREAT, 0666, 1); sem_wait(sem); /* 臨界區(qū)讀寫共享內(nèi)存 */ sem_post(sem);還有一個我踩過的坑共享內(nèi)存的名字要以斜杠開頭比如/my_shm不能帶多余的斜杠。在嵌入式文件系統(tǒng)比較精簡的環(huán)境里/dev/shm可能沒掛載POSIX共享內(nèi)存會創(chuàng)建/打開失敗。遇到這類問題檢查一下/dev/shm是否存在以及權(quán)限是否正常。如果確實沒有也可以用老牌的System V接口或者干脆退回mmap某個普通文件匿名映射配合fork共享也算一種辦法但寫文件有持久化開銷一般我沒這么干。6. 進(jìn)程實戰(zhàn)一個嵌入式多進(jìn)程系統(tǒng)的完整設(shè)計6.1 一個多進(jìn)程采集系統(tǒng)的模塊劃分拿我之前做過的某工業(yè)數(shù)據(jù)采集網(wǎng)關(guān)來拆解硬件平臺是一塊ARM板內(nèi)存256MB跑精簡的嵌入式Linux。網(wǎng)關(guān)要完成的事情有采集多路串口傳感器的數(shù)據(jù)、把數(shù)據(jù)經(jīng)過網(wǎng)絡(luò)協(xié)議上報到中心服務(wù)器、在本地屏幕上顯示運行狀態(tài)、接收遠(yuǎn)程配置更新并生效。我沒有把這些功能寫成一個巨型進(jìn)程而是拆成了四個進(jìn)程采集進(jìn)程負(fù)責(zé)輪詢多路串口、解析協(xié)議把原始數(shù)據(jù)整理成標(biāo)準(zhǔn)格式寫入共享內(nèi)存。這個進(jìn)程最復(fù)雜牽涉串口狀態(tài)異常、通信超時等一堆判斷邏輯。上報進(jìn)程從共享內(nèi)存讀取數(shù)據(jù)通過TCP協(xié)議上報。它只關(guān)心數(shù)據(jù)有沒有新的不知道串口是什么、傳感器是什么協(xié)議。顯示進(jìn)程從共享內(nèi)存讀狀態(tài)更新本地屏幕。管理進(jìn)程接收遠(yuǎn)程配置通過信號和共享內(nèi)存把新的配置參數(shù)下發(fā)給采集進(jìn)程和上報進(jìn)程。進(jìn)程通信方式的選擇思路是采集進(jìn)程和上報進(jìn)程、顯示進(jìn)程之間大塊周期性數(shù)據(jù)用共享內(nèi)存。管理進(jìn)程發(fā)配置變更通知用信號SIGUSR1再配合共享內(nèi)存里的配置區(qū)。進(jìn)程崩潰恢復(fù)管理進(jìn)程周期性檢測其他進(jìn)程存活狀態(tài)發(fā)現(xiàn)異常直接拉起這個在嵌入式網(wǎng)關(guān)里就是心跳?；畹倪壿嫛９蚕韮?nèi)存設(shè)計概要#define DATA_SHM_SIZE (8 * 1024 * 1024) struct gateway_shm { sem_t data_sem; /* 數(shù)據(jù)區(qū)互斥信號量 */ unsigned int seq; /* 數(shù)據(jù)序號便于消費端判斷新數(shù)據(jù) */ size_t valid_len; /* 本次數(shù)據(jù)有效長度 */ unsigned char data[0]; /* 數(shù)據(jù)區(qū) */ };采集進(jìn)程寫數(shù)據(jù)前sem_wait寫完sem_post上報進(jìn)程讀取前也sem_wait/sem_post。seq序號是用來判斷有沒有新的一幀數(shù)據(jù)的續(xù)傳過程中如果seq沒變化上報進(jìn)程就不重復(fù)上報。這個設(shè)計在初期看起來簡單但實際運行非常穩(wěn)跑了幾個月基本沒出過問題。6.2 進(jìn)程同步與資源競爭的排查多進(jìn)程共享資源的核心問題就是競爭條件。嵌入式里最典型的競爭場景就兩個共享內(nèi)存讀寫競爭、日志文件多進(jìn)程寫入競爭。我在項目里排查過一個詭異的bug上報進(jìn)程偶爾上報的幀數(shù)據(jù)校驗不對但采集進(jìn)程自己檢查數(shù)據(jù)是完好的。查了一下午最后定位到是共享內(nèi)存的讀寫沒有加信號量保護(hù)。采集進(jìn)程在寫數(shù)據(jù)時上報進(jìn)程恰好也在讀讀到一半被覆蓋了導(dǎo)致半幀數(shù)據(jù)。修復(fù)方式就是在讀寫共享內(nèi)存前后加上互斥信號量。這個案例給我最深的教訓(xùn)是不要覺得數(shù)據(jù)量小、寫在瞬間完成就省信號量任何跨進(jìn)程共享的可變數(shù)據(jù)都必須有同步機制沒有例外。日志文件的競爭問題也很常見。多個進(jìn)程同時open同一個日志文件然后write由于O_APPEND模式下每次write是原子的所以不會丟行但多進(jìn)程交錯寫入會導(dǎo)致日志順序混亂、難以排查問題。我的做法是讓日志統(tǒng)一走一個獨立的日志進(jìn)程其他進(jìn)程通過管道或者socket把日志消息發(fā)給它由日志進(jìn)程串行落盤。這樣日志順序始終是對的排查問題時不用腦補。另外一個在嵌入式里經(jīng)常被忽略的競爭資源是同一個串口或者同一個外設(shè)。如果兩個進(jìn)程同時操作同一個串口數(shù)據(jù)就會互相干擾。解決方式就是通過一個設(shè)備管理進(jìn)程獨占這個串口其他進(jìn)程都用IPC給它發(fā)讀寫請求由它統(tǒng)一調(diào)度。這種單設(shè)備單進(jìn)程的架構(gòu)模式在嵌入式里非常實用。6.3 可復(fù)用的進(jìn)程啟動與監(jiān)控框架基于上面這個項目我沉淀了一套很輕量的進(jìn)程骨架后面做其他嵌入式產(chǎn)品也一直在復(fù)用。核心思路就是這個小流程統(tǒng)一封裝一個進(jìn)程主循環(huán)框架包含信號處理、日志初始化、看門狗上報。每個業(yè)務(wù)進(jìn)程都實現(xiàn)init()和loop()兩個函數(shù)主循環(huán)死循環(huán)調(diào)loop()。管理進(jìn)程通過一個pid文件或者共享內(nèi)存里各自對應(yīng)的存活標(biāo)志位來判斷進(jìn)程狀態(tài)。進(jìn)程崩潰時由系統(tǒng)啟動框架如supervisor或者自己寫個shell監(jiān)控腳本拉起來必要時配合硬件看門狗重啟整個系統(tǒng)。這種輕框架 多進(jìn)程的模式比一個進(jìn)程里寫幾百個線程要容易維護(hù)太多了。進(jìn)程掛了就拉起數(shù)據(jù)通過共享內(nèi)存交換模塊職責(zé)分明排錯不需要跨著整個系統(tǒng)猜。7. 常見問題與排查技巧7.1 嵌入式Linux進(jìn)程問題速查把我這些年遇到過的進(jìn)程相關(guān)問題整理成一張速查表順手就能當(dāng)排查手冊用現(xiàn)象原因排查方向系統(tǒng)進(jìn)程數(shù)持續(xù)增長子進(jìn)程退出未被回收僵尸堆積ps -ef查Z狀態(tài)檢查父進(jìn)程是否調(diào)用了waitpidfork返回失敗進(jìn)程數(shù)達(dá)到上限、內(nèi)存不足ulimit -u查看進(jìn)程限制free查內(nèi)存新進(jìn)程不干活但沒退出等某個IPC條件不滿足阻塞中cat /proc/PID/stack或strace看阻塞點共享內(nèi)存讀寫數(shù)據(jù)錯亂缺互斥信號量代碼審查檢查臨界區(qū)保護(hù)兩個進(jìn)程同時訪問串口沖突設(shè)備被多處打開查lsof /dev/ttyS*改成單進(jìn)程獨占程序退出后日志丟失exit時緩沖區(qū)未刷新或信號后函數(shù)不完整檢查是否用了_exit、是否優(yōu)雅關(guān)停SIGTERM殺掉進(jìn)程但資源沒釋放沒捕獲SIGTERM默認(rèn)直接死自己注冊SIGTERM處理做清理再退進(jìn)程變成孤兒后行為異常孤兒依賴了父進(jìn)程的資源守護(hù)進(jìn)程化要徹底別繼承終端和父進(jìn)程fd排查手段優(yōu)先用這幾個ps -ef # 總覽進(jìn)程狀態(tài) ps -o pid,ppid,stat,cmd -A # 看關(guān)注字段 top # 看CPU、內(nèi)存占用 cat /proc/PID/status # 看單進(jìn)程詳細(xì)狀態(tài) cat /proc/PID/wchan # 看進(jìn)程阻塞在內(nèi)核哪個函數(shù) strace -p PID # 跟蹤進(jìn)程的系統(tǒng)調(diào)用嵌入式板子上如果沒有strace可以臨時編譯一個靜態(tài)版放進(jìn)去這是我常用的辦法。strace對排查進(jìn)程卡住不動的問題幾乎是神器能看到它阻塞在哪個syscall上。7.2 實戰(zhàn)中容易忽視的細(xì)節(jié)與經(jīng)驗先聊文件描述符泄漏。一個進(jìn)程長期運行如果每次循環(huán)里打開文件或socket后忘了close文件描述符會慢慢漲到上限然后程序開始異常。排查方法很簡單看/proc/PID/fd目錄里的描述符合不合理、數(shù)量是否持續(xù)上漲。fd泄漏是嵌入式守護(hù)進(jìn)程最常見的隱形bug之一我建議在你的進(jìn)程骨架里定期統(tǒng)計fd數(shù)量并打日志。再聊環(huán)境變量的坑。用exec族時子進(jìn)程繼承父進(jìn)程的環(huán)境變量。但有些嵌入式庫在找不到某個環(huán)境變量時會靜默降級比如NFS、時區(qū)、語言相關(guān)的環(huán)境變量可能導(dǎo)致行為異常。排查時可以用env命令看當(dāng)前環(huán)境變量必要時在代碼里用setenv顯式設(shè)置。還有一個心得是關(guān)于信號與主循環(huán)的協(xié)作。我曾經(jīng)在一個進(jìn)程里用鬧鐘信號SIGALRM做定時采樣信號處理函數(shù)里直接調(diào)用了一個業(yè)務(wù)函數(shù)。后來采樣周期要求從100ms改成20ms驚喜發(fā)生了主循環(huán)邏輯被信號打斷的頻率變高了某些臨界區(qū)被插入執(zhí)行數(shù)據(jù)出現(xiàn)偶發(fā)不一致。最后改成信號只置標(biāo)志位主循環(huán)通過select或者epoll_wait帶超時來處理定時任務(wù)問題徹底消失?，F(xiàn)在我的代碼里信號處理函數(shù)里絕對不碰業(yè)務(wù)邏輯這已經(jīng)成了我的鐵律。線程與進(jìn)程混合使用時也要注意多線程進(jìn)程里fork子進(jìn)程里只保留調(diào)用fork的那個線程其他線程都沒了。如果子進(jìn)程要訪問那些線程持有的鎖可能直接死鎖。所以設(shè)計上盡量讓進(jìn)程和線程的邊界清晰不要搞大雜燴。嵌入式產(chǎn)品穩(wěn)定優(yōu)先能用多進(jìn)程劃分的模塊就不強行用多線程。最后講一個看門狗相關(guān)的經(jīng)驗。嵌入式Linux系統(tǒng)一般會用硬件看門狗或者軟件看門狗保證系統(tǒng)不徹底死掉。多進(jìn)程架構(gòu)里軟件看門狗的邏輯通常是一個監(jiān)控進(jìn)程周期性檢查各業(yè)務(wù)進(jìn)程的心跳心跳異常就重啟對應(yīng)進(jìn)程如果監(jiān)控進(jìn)程本身也不行了硬件看門狗在規(guī)定時間內(nèi)沒被喂狗整機復(fù)位。這個層級化的保活機制在多進(jìn)程架構(gòu)下實現(xiàn)起來非常自然也是一個進(jìn)程架構(gòu)相對線程架構(gòu)的突出優(yōu)勢。我曾經(jīng)在采集網(wǎng)關(guān)里把每個進(jìn)程的心跳寫進(jìn)共享內(nèi)存管理進(jìn)程每秒檢查一次連續(xù)三次心跳超時就果斷重啟對應(yīng)進(jìn)程實測整套系統(tǒng)連續(xù)運行數(shù)月沒有死透的情況。個人經(jīng)驗方面做進(jìn)程開發(fā)調(diào)試時代碼里多打日志、日志里帶上PID和時間戳是成本最低的排查手段。嵌入式上沒有IDE調(diào)試器那么方便很多時候就是靠日志定位問題。但日志也不能隨便打每個循環(huán)里打一堆反而干擾問題定位建議關(guān)鍵決策點打日志比如進(jìn)程啟動、退出、收到信號、寫共享內(nèi)存成功失敗。日志級別控制手段也要有線上跑release日志測試環(huán)境開debug日志。還有個容易翻車的點嵌入式系統(tǒng)有時區(qū)設(shè)置或者環(huán)境變量缺失導(dǎo)致進(jìn)程啟動失敗。如果一個進(jìn)程起不來先手動在終端里跑一下看它打印什么錯誤然后再去看啟動腳本哪里不對。很多啟動失敗其實是動態(tài)庫找不到ldd可以查依賴、配置文件路徑不對、或者權(quán)限不足跟進(jìn)程本身的邏輯沒什么關(guān)系。做嵌入式Linux進(jìn)程開發(fā)的過程說到底就是在并發(fā)和隔離這兩件事上做平衡。進(jìn)程給了你隔離的穩(wěn)定邊界但同時也把并發(fā)、通信、同步這些復(fù)雜度帶進(jìn)來了。你能把這些復(fù)雜度一個一個地控制住這個產(chǎn)品的穩(wěn)定性和可維護(hù)性就上來了。上面這些坑和經(jīng)驗都是我在真實項目里一步步踩出來的當(dāng)你自己摸著石頭過河時希望這篇內(nèi)容能幫你少走幾步彎路。 嵌入式Linux進(jìn)程實戰(zhàn)：從fork、僵尸進(jìn)程到多進(jìn)程通信
做嵌入式Linux開發(fā)繞不開進(jìn)程。我剛開始接觸嵌入式Linux應(yīng)用層時總覺得進(jìn)程這玩意不就是幾個API嗎fork一下、exec一下死記硬背就完事。但真到項目里被僵尸進(jìn)程、資源競爭、IPC選型這些破事折磨過幾輪之后才明白進(jìn)程是理解整個Linux應(yīng)用開發(fā)的基石地基沒打牢上層寫再多業(yè)務(wù)代碼都是空中樓閣。這篇博文就圍繞嵌入式場景下的進(jìn)程實戰(zhàn)來寫從核心概念、生命周期、創(chuàng)建方式、回收治理到進(jìn)程間通信和典型的多進(jìn)程項目實操全部按我實際做過的項目和踩過的坑來展開。適合剛?cè)腴T嵌入式Linux應(yīng)用開發(fā)的同學(xué)也適合那些會調(diào)API但對進(jìn)程底層行為理解不透、想在項目里少踩坑的開發(fā)者。1. 為什么嵌入式Linux應(yīng)用開發(fā)要學(xué)透進(jìn)程1.1 進(jìn)程在嵌入式系統(tǒng)里的位置先看一個現(xiàn)實問題MCU裸機開發(fā)時代整個系統(tǒng)就一個死循環(huán)在跑所有功能都是輪詢中斷代碼寫起來簡單直接。但上了嵌入式Linux動不動就是幾百萬行代碼多個功能模塊要同時跑還要保證某個模塊掛掉不影響整體系統(tǒng)。這時候進(jìn)程就是最基本的隔離單元——每個進(jìn)程有獨立的地址空間、獨立的資源一個進(jìn)程崩潰了內(nèi)核會回收它的資源其他進(jìn)程該干嘛繼續(xù)干嘛。我在一個車載信息終端的項目里遇到過這種情況顯示模塊需要常駐運行但負(fù)責(zé)數(shù)據(jù)上報的網(wǎng)絡(luò)模塊時不時會因為運營商網(wǎng)絡(luò)異常而卡死。如果所有邏輯都在一個進(jìn)程里網(wǎng)絡(luò)模塊一卡整個屏幕就跟著假死。后來把顯示、網(wǎng)絡(luò)上報、外設(shè)監(jiān)控拆成三個獨立進(jìn)程網(wǎng)絡(luò)模塊掛了看門狗自動拉起它顯示模塊完全不受影響。這就是進(jìn)程隔離在嵌入式系統(tǒng)里最典型、也是最核心的作用。還有一點容易被忽略Linux內(nèi)核的進(jìn)程調(diào)度器本身就是為多任務(wù)場景設(shè)計的。嵌入式Linux不是讓你像裸機那樣自己寫調(diào)度器而是讓你站在進(jìn)程這個抽象層上做產(chǎn)品設(shè)計。你只需要關(guān)心這個模塊放哪個進(jìn)程里、進(jìn)程之間怎么通信剩下的CPU調(diào)度、時間片分配、優(yōu)先級搶占內(nèi)核全都幫你處理好了。1.2 進(jìn)程與線程的選擇邏輯很多新手上來就糾結(jié)到底用多進(jìn)程還是多線程我在團隊里帶新人時給過一個可以快速落地的判斷標(biāo)準(zhǔn)模塊之間需要強隔離、需要獨立崩潰恢復(fù)能力的選進(jìn)程。模塊之間需要頻繁、大量、低延遲地共享數(shù)據(jù)性能要求極高的選線程。嵌入式系統(tǒng)內(nèi)存非常吃緊比如總內(nèi)存只有64MB進(jìn)程數(shù)量要克制優(yōu)先用線程。安全等級要求高某個模塊不能被其他模塊拖垮必須用進(jìn)程隔離。從開發(fā)成本來說進(jìn)程間通信比線程間共享內(nèi)存要繁瑣寫起來多不少樣板代碼。但進(jìn)程帶來的穩(wěn)定性收益在嵌入式這種無人值守、連續(xù)運行幾個月不重啟的場景里是非常值得的。我個人的原則是能用進(jìn)程解決穩(wěn)定性問題的就別省這個成本省下的調(diào)試時間遠(yuǎn)超多寫的那些代碼。2. 進(jìn)程的核心概念與生命周期2.1 PID與進(jìn)程描述符進(jìn)程在Linux里有唯一的身份標(biāo)識就是PIDProcess ID。PID是int類型從1開始遞增分配達(dá)到上限后會回繞同時為了避免pid重用得太快引發(fā)安全問題內(nèi)核會有pid_max之類的限制。嵌入式的產(chǎn)品里PID一般不會有什么問題但了解這個機制能幫你理解為什么某些系統(tǒng)工具會顯示PID很大。比PID更底層的概念是進(jìn)程描述符也就是內(nèi)核里的task_struct結(jié)構(gòu)體。它包含了進(jìn)程的所有信息PID、PPID父進(jìn)程PID、狀態(tài)、優(yōu)先級、打開的文件描述符表、內(nèi)存地址空間描述、信號處理函數(shù)指針、各種計時器和統(tǒng)計信息。你可以這樣理解task_struct就是進(jìn)程在內(nèi)核里的檔案袋所有跟進(jìn)程相關(guān)的東西都裝在里面。在嵌入式應(yīng)用層開發(fā)時常用這幾個接口獲取進(jìn)程信息#include unistd.h #include sys/types.h pid_t getpid(void); // 獲取當(dāng)前進(jìn)程PID pid_t getppid(void); // 獲取父進(jìn)程PID查看系統(tǒng)進(jìn)程狀態(tài)用ps命令就夠ps -ef ps -aux嵌入式系統(tǒng)如果busybox裁剪過可能沒有完整ps但通常會有簡化版的ps用法類似。2.2 進(jìn)程狀態(tài)機與狀態(tài)切換進(jìn)程在生命周期里不是一直運行的它會在這幾個狀態(tài)之間切換RTASK_RUNNING可執(zhí)行狀態(tài)。注意這個狀態(tài)包含兩種情況——正在CPU上運行或者排在就緒隊列里等待被調(diào)度。也就是說R不代表正在跑它只代表隨時可以跑。STASK_INTERRUPTIBLE可中斷睡眠。進(jìn)程在等待某個條件滿足比如等鍵盤輸入、等socket數(shù)據(jù)可以被信號喚醒。這是嵌入式進(jìn)程最常見的狀態(tài)大量時間都耗在這里。DTASK_UNINTERRUPTIBLE不可中斷睡眠。一般在等待磁盤IO等內(nèi)核操作完成不能響應(yīng)信號。如果系統(tǒng)里有大量D狀態(tài)進(jìn)程且長時間不退出去通常是IO子系統(tǒng)出了問題要留意。TTASK_STOPPED停止?fàn)顟B(tài)。通過SIGSTOP信號進(jìn)入SIGCONT恢復(fù)。ZTASK_ZOMBIE僵尸狀態(tài)。進(jìn)程已經(jīng)退出但資源還沒有被父進(jìn)程回收。嵌入式開發(fā)里最常打交道的就是僵尸狀態(tài)這個問題我放到后面專門說。你只要記住一句口訣Z狀態(tài)的進(jìn)程已經(jīng)死了它的靈魂task_struct還在內(nèi)核里飄著等父進(jìn)程來收尸。2.3 進(jìn)程、線程、程序的區(qū)別這三個詞經(jīng)常被混用但差別很關(guān)鍵程序是靜態(tài)的就是磁盤上的一個ELF文件躺著不動。進(jìn)程是程序跑起來之后的動態(tài)實體有自己的地址空間、文件描述符、信號處理等一堆運行時資源。線程是進(jìn)程內(nèi)部的執(zhí)行單元同一個進(jìn)程里的多個線程共享地址空間和大部分資源各自有獨立的棧和寄存器上下文。用生活場景打個比方程序是一本菜譜進(jìn)程是照著菜譜在廚房里做菜的這個操作過程線程則是操作過程里掌勺、切菜、配菜這些同時進(jìn)行的動作。菜譜可以復(fù)制很多份就像同一個程序可以跑出多個進(jìn)程比如系統(tǒng)里開了好幾個相同名稱的shell一個廚房里可以多個人協(xié)作就像進(jìn)程里可以開多個線程。在嵌入式Linux里線程的實現(xiàn)是NPTLNative POSIX Thread Library本質(zhì)上是基于clone系統(tǒng)調(diào)用來創(chuàng)建的clone和fork共享了很多底層機制。理解這一點很重要線程并不是什么神秘的東西它就是共享了地址空間等資源的進(jìn)程變體。3. 進(jìn)程創(chuàng)建的三種姿勢與原理3.1 fork系統(tǒng)調(diào)用的行為與寫時拷貝創(chuàng)建進(jìn)程最經(jīng)典的方式就是fork。新手理解fork最繞的一個點就是fork調(diào)用一次返回兩次。父進(jìn)程里返回子進(jìn)程的PID大于0子進(jìn)程里返回0失敗返回-1。你用返回值區(qū)分父子身份然后讓父子進(jìn)程走不同的代碼分支。先看最基本的代碼#include stdio.h #include unistd.h #include sys/types.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork error); return -1; } else if (pid 0) { printf(child process, pid%d, ppid%d\n, getpid(), getppid()); } else { printf(parent process, pid%d, child pid%d\n, getpid(), pid); } return 0; }編譯運行之后你會發(fā)現(xiàn)一個有意思的現(xiàn)象兩個printf的輸出順序不一定固定父子進(jìn)程誰先跑完全由內(nèi)核調(diào)度器決定。這也是多進(jìn)程編程和裸機順序執(zhí)行思維最大的差異點——從fork返回那一刻起兩個執(zhí)行流就是并發(fā)的、不確定的。fork背后有一個極其重要的機制叫寫時拷貝Copy-On-WriteCOW。傳統(tǒng)的fork會立刻把父進(jìn)程整個地址空間復(fù)制一份給子進(jìn)程成本極高。所以現(xiàn)代Linux內(nèi)核在fork時不真正拷貝物理內(nèi)存而是把父子進(jìn)程的頁表都指向同一塊物理內(nèi)存并把這些頁標(biāo)記成只讀。如果父子進(jìn)程誰也沒改數(shù)據(jù)就一直共享這塊內(nèi)存一旦某個進(jìn)程要寫某個頁內(nèi)核才會觸發(fā)缺頁異常真正拷貝一份出來讓寫操作的進(jìn)程擁有自己的副本。這個機制在嵌入式環(huán)境里意義很大雖然我們有soc內(nèi)存動輒幾百MB甚至上GB但系統(tǒng)內(nèi)存依然寶貴COW讓fork的啟動成本變得很低。特別是在fork后馬上exec執(zhí)行新程序這種典型場景里COW保證了中間幾乎零拷貝。3.2 vfork與exec族的搭配使用vfork是fork的老前輩它的語義是創(chuàng)建子進(jìn)程掛起父進(jìn)程直到子進(jìn)程調(diào)用exec或者退出。這么做是為了避免在早期沒有MMU的Linux系統(tǒng)上復(fù)制頁表。子進(jìn)程和父進(jìn)程完全共享地址空間連棧都共享所以在vfork之后、exec之前子進(jìn)程絕對不能修改任何數(shù)據(jù)否則會搞壞父進(jìn)程的現(xiàn)場?，F(xiàn)代Linux基本上不需要用vfork了COW機制已經(jīng)完美解決了fork的性能問題。我在代碼評審里看到有人用vfork基本都是歷史習(xí)慣我會建議改成fork。有個別嵌入式場景還在用vfork純粹是為了極致地省一點fork時間但收益極小、風(fēng)險極高不推薦。exec族真正干的事情是用一個新的程序完全替換當(dāng)前進(jìn)程的代碼段、數(shù)據(jù)段、堆和棧。進(jìn)程PID不變內(nèi)核說你還是你但你已經(jīng)不是你了。exec族函數(shù)一共六個int execl(const char *path, const char *arg, ...); int execlp(const char *file, const char *arg, ...); int execle(const char *path, const char *arg, ..., char *const envp[]); int execv(const char *path, char *const argv[]); int execvp(const char *file, char *const argv[]); int execvpe(const char *file, char *const argv[], char *const envp[]);帶l的是參數(shù)列表方式帶v的是參數(shù)數(shù)組方式帶p的是會在PATH環(huán)境變量里搜索可執(zhí)行文件帶e的是可以顯式傳入環(huán)境變量。記不住就記一條在嵌入式里最常用的是execlp和execvp因為它們可以按PATH找程序省得路徑寫錯踩坑。常見的一個組合用法是fork之后在子進(jìn)程里exec#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { /* 子進(jìn)程執(zhí)行外部程序 */ execlp(ls, ls, -l, NULL); /* exec執(zhí)行成功的話到不了這里 */ perror(execlp error); _exit(1); } else if (pid 0) { wait(NULL); /* 父進(jìn)程等待子進(jìn)程結(jié)束 */ } return 0; }這里有個細(xì)節(jié)exec失敗后要調(diào)用_exit而不是exit。因為exit會刷新stdio緩沖區(qū)如果exec失敗時緩沖區(qū)里還有從父進(jìn)程繼承來的數(shù)據(jù)可能會被寫兩次。_exit直接進(jìn)入內(nèi)核退出不碰用戶態(tài)緩沖區(qū)更安全。3.3 父子進(jìn)程的資源繼承清單新手經(jīng)常會問fork之后子進(jìn)程到底繼承了父進(jìn)程的什么簡單記幾乎繼承了所有的用戶態(tài)資源。繼承的資源包括環(huán)境變量、打開的文件描述符表、當(dāng)前工作目錄、信號處理方式注意要捕獲的信號處理函數(shù)被繼承被忽略的信號設(shè)置也被繼承但未決信號不繼承、進(jìn)程組ID、會話ID、控制終端等。不繼承的東西也要記住子進(jìn)程擁有全新的PID必然不同各種鎖的狀態(tài)不繼承未決的信號不繼承計時器不繼承還有進(jìn)程的資源使用計數(shù)會清零。這里面最坑的是文件描述符繼承。如果在父進(jìn)程里打開了一個文件fork之后子進(jìn)程也持有這個文件描述符指向同一個文件描述。這會導(dǎo)致兩個進(jìn)程共享同一個文件偏移量。如果父子進(jìn)程同時往同一文件寫數(shù)據(jù)你會看到數(shù)據(jù)交錯甚至覆蓋因為共享偏移會互相影響。解決思路通常是子進(jìn)程需要讀寫文件時在子進(jìn)程里自己open一個或者fork之前別打開這個文件、fork之后各開各的。4. 子進(jìn)程回收與僵尸進(jìn)程治理4.1 wait與waitpid的阻塞和非阻塞回收子進(jìn)程退出后內(nèi)核會保留它的task_struct直到父進(jìn)程調(diào)用wait或者waitpid把它收走這個收走的過程也叫回收。如果不回收子進(jìn)程就成了僵尸進(jìn)程?；窘涌?include sys/wait.h pid_t wait(int *status); pid_t waitpid(pid_t pid, int *status, int options);wait是阻塞的只要有子進(jìn)程沒退出它就一直卡著。waitpid更靈活可以通過參數(shù)控制等待哪個子進(jìn)程、是否阻塞。waitpid的pid參數(shù)要認(rèn)真記pid 0等待指定PID的子進(jìn)程。pid -1等待任意子進(jìn)程相當(dāng)于wait。pid 0等待與當(dāng)前進(jìn)程同進(jìn)程組的任意子進(jìn)程。pid -1等待進(jìn)程組ID等于|pid|的任意子進(jìn)程。options參數(shù)至少記住兩個0阻塞等待。WNOHANG非阻塞如果沒有子進(jìn)程退出立即返回0。還有WUNTRACED子進(jìn)程停止也返回和WCONTINUED在嵌入式里用得少了解即可。status參數(shù)用來獲取子進(jìn)程的退出信息需要用宏來解析int status; pid_t ret waitpid(pid, status, WNOHANG); if (ret 0) { if (WIFEXITED(status)) { printf(normal exit, status%d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(killed by signal %d\n, WTERMSIG(status)); } }實際開發(fā)里我強烈建議統(tǒng)一用waitpid WNOHANG的模式寫子進(jìn)程回收邏輯尤其是父進(jìn)程有主循環(huán)的場景嵌入式很多進(jìn)程都長這樣while (1) { pid_t ret waitpid(-1, status, WNOHANG); if (ret 0) { /* 有子進(jìn)程退出了處理回收 */ } /* 繼續(xù)干父進(jìn)程自己的事 */ ... }這樣父進(jìn)程既不會阻塞在等子進(jìn)程上也不會漏掉任何一個子進(jìn)程退出的回收時機。4.2 僵尸進(jìn)程的產(chǎn)生與清理僵尸進(jìn)程是怎么來的子進(jìn)程先退出父進(jìn)程還沒來得及調(diào)用wait。這個還沒可以是微秒也可以是永遠(yuǎn)。如果父進(jìn)程壓根不調(diào)用wait那子進(jìn)程變成僵尸之后就永遠(yuǎn)占著一個內(nèi)核task_struct無法釋放。嵌入式系統(tǒng)里僵尸進(jìn)程的危害比其他場景更大因為嵌入式設(shè)備的資源本來就緊。一個兩個僵尸可能看不出來但如果父進(jìn)程反復(fù)創(chuàng)建子進(jìn)程又不管僵尸越積越多最終會導(dǎo)致系統(tǒng)無法創(chuàng)建新進(jìn)程——進(jìn)程數(shù)達(dá)到上限。清理僵尸進(jìn)程有幾種辦法方法一最關(guān)鍵也最常用的在父進(jìn)程里注冊SIGCHLD信號處理函數(shù)。子進(jìn)程退出時內(nèi)核會自動給父進(jìn)程發(fā)SIGCHLD信號。父進(jìn)程在這個信號處理函數(shù)里調(diào)用waitpid回收。#include signal.h void sigchld_handler(int sig) { int status; pid_t pid; while ((pid waitpid(-1, status, WNOHANG)) 0) { /* 回收一個已退出的子進(jìn)程 */ } } int main(void) { struct sigaction sa; sa.sa_handler sigchld_handler; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; sigaction(SIGCHLD, sa, NULL); /* 正常fork子進(jìn)程 */ fork(); ... }注意信號處理函數(shù)里要用while循環(huán)把waitpid調(diào)到底因為信號可能被合并一次信號到達(dá)可能對應(yīng)多個子進(jìn)程退出只回收一個會漏。方法二子進(jìn)程還沒有孫子進(jìn)程的話可以fork之后立刻wait父子同步運行子進(jìn)程退出時父進(jìn)程馬上回收。適合簡單的父進(jìn)程調(diào)子進(jìn)程干活的場景。方法三讓子進(jìn)程被init進(jìn)程收養(yǎng)。子進(jìn)程變成孤兒后會被init接管init會自動回收孫輩的僵尸。這個思路通常用在守護(hù)進(jìn)程設(shè)計里。還有一個必須強調(diào)的坑信號處理函數(shù)里能用waitpid嗎能用但要小心。waitpid不是異步信號安全函數(shù)async-signal-safe列表里百分百安全的但waitpid本身在POSIX里有爭議實際Linux使用waitpid在信號處理函數(shù)里回收子進(jìn)程是非常普遍的實踐。更穩(wěn)妥的方式是在信號處理函數(shù)里只置一個flag然后在主循環(huán)里檢查flag再調(diào)waitpid。我在實際項目里兩種都寫過如果代碼量不大且邏輯簡單直接在handler里waitpid也沒問題如果主循環(huán)邏輯復(fù)雜、對可靠性要求高建議用flag方式。4.3 孤兒進(jìn)程與守護(hù)進(jìn)程化子進(jìn)程的父進(jìn)程先退出了子進(jìn)程就成了孤兒。孤兒不會被丟棄而是被直接過繼給init/systemd進(jìn)程通常PID為1由它負(fù)責(zé)回收。所以孤兒進(jìn)程一般不會變成僵尸。在嵌入式里我們更關(guān)心的是反過來一種場景怎么主動脫單把自己變成孤兒然后讓init收養(yǎng)自己。這就是守護(hù)進(jìn)程daemon化的核心步驟之一。一個標(biāo)準(zhǔn)的守護(hù)進(jìn)程化流程通常是調(diào)用fork父進(jìn)程退出子進(jìn)程繼續(xù)。子進(jìn)程調(diào)用setsid創(chuàng)建新的會話徹底脫離控制終端。再次fork讓新進(jìn)程不再是會話首進(jìn)程防止它重新獲取控制終端。修改當(dāng)前工作目錄到根目錄或者其他固定目錄。重定向標(biāo)準(zhǔn)輸入輸出錯誤到/dev/null或日志文件。設(shè)置文件權(quán)限掩碼umask(0)。如果你用的是glibc可以直接調(diào)用daemon(0, 0)函數(shù)一步完成上面大部分工作。但嵌入式系統(tǒng)用的庫不一定有daemon函數(shù)或者你想精細(xì)控制每一步就手寫。很多嵌入式進(jìn)程不要求完全脫離終端直接寫一個正常的一直運行的進(jìn)程配合啟動腳本用nohup或者啟動框架管理也是常見做法。守護(hù)進(jìn)程化的核心意義是進(jìn)程生命周期不再依賴終端和父進(jìn)程哪怕登錄會話關(guān)閉進(jìn)程照樣跑。5. 嵌入式場景下的進(jìn)程間通信實戰(zhàn)5.1 管道通信最直接的進(jìn)程間數(shù)據(jù)傳輸進(jìn)程間通信IPC在嵌入式Linux里是重頭戲。不同進(jìn)程有獨立地址空間無法直接訪問對方內(nèi)存必須通過內(nèi)核提供的機制來傳數(shù)據(jù)。管道是最基礎(chǔ)的一種IPC分兩種匿名管道pipe只能用于有親緣關(guān)系的進(jìn)程之間父子進(jìn)程、兄弟進(jìn)程。通過pipe()創(chuàng)建一對文件描述符fd[0]是讀端fd[1]是寫端。父進(jìn)程寫、子進(jìn)程讀的經(jīng)典流程是pipe創(chuàng)建管道fork之后寫方關(guān)閉讀端讀方關(guān)閉寫端雙方通過管道傳數(shù)據(jù)。命名管道FIFO通過mkfifo創(chuàng)建文件系統(tǒng)里有一個可見的管道文件任意兩個進(jìn)程只要打開同一個FIFO文件就能通信不需要親緣關(guān)系。嵌入式里匿名管道最常見的用途是父進(jìn)程把某個子進(jìn)程的輸出抓回來。比如父進(jìn)程啟動一個子進(jìn)程跑一個外設(shè)檢測程序然后讀它的標(biāo)準(zhǔn)輸出#include stdio.h #include unistd.h #include string.h int main(void) { int fds[2]; pipe(fds); pid_t pid fork(); if (pid 0) { /* 子進(jìn)程把標(biāo)準(zhǔn)輸出重定向到管道寫端 */ close(fds[0]); dup2(fds[1], STDOUT_FILENO); close(fds[1]); execlp(cat, cat, /proc/cpuinfo, NULL); _exit(1); } /* 父進(jìn)程從管道讀端讀取數(shù)據(jù) */ close(fds[1]); char buf[256]; ssize_t n; while ((n read(fds[0], buf, sizeof(buf))) 0) { write(STDOUT_FILENO, buf, n); } close(fds[0]); return 0; }這里dup2把子進(jìn)程的標(biāo)準(zhǔn)輸出重定向到管道寫端。管道的讀寫是阻塞式的讀端在管道沒數(shù)據(jù)時會阻塞寫端在管道緩沖區(qū)滿時會阻塞。管道緩沖區(qū)默認(rèn)大小在Linux上一般是64KB內(nèi)核版本不同有差異如果你寫的數(shù)據(jù)超過緩沖區(qū)大小且讀端沒及時讀寫進(jìn)程會卡住。所以管道適合傳小數(shù)據(jù)量、流式的數(shù)據(jù)不適合傳大塊數(shù)據(jù)。5.2 信號機制異步事件處理信號在嵌入式里主要用來處理異步事件和簡單的通知。除了前面說的SIGCHLD常見的還有SIGTERM15默認(rèn)終止進(jìn)程可被捕獲和忽略常用于優(yōu)雅關(guān)停。SIGKILL9強制終止進(jìn)程不可捕獲、不可忽略。別指望在SIGKILL里做清理。SIGINT2CtrlC觸發(fā)。SIGALRM14定時器到期觸發(fā)。注冊信號處理函數(shù)建議用sigaction而不是老的signal函數(shù)因為signal在不同Unix系統(tǒng)上語義有差異sigaction行為是POSIX標(biāo)準(zhǔn)定義的更可靠struct sigaction sa; sa.sa_handler handler_func; sigemptyset(sa.sa_mask); sa.sa_flags 0; sigaction(SIGTERM, sa, NULL);信號處理函數(shù)里能做什么事情限制非常多。理論上是只做異步信號安全的事操作變量置標(biāo)志位、write到管道/文件、調(diào)用signal相關(guān)的函數(shù)都是可以的。但malloc、printf、fprintf這類不能保證安全因為可能在主程序里正執(zhí)行到一半、信號處理函數(shù)又進(jìn)來了導(dǎo)致堆狀態(tài)錯亂。我自己寫嵌入式進(jìn)程的關(guān)停邏輯時典型做法是static volatile sig_atomic_t g_stop_flag 0; void term_handler(int sig) { g_stop_flag 1; } int main(void) { /* 注冊SIGTERM/SIGINT */ ... while (!g_stop_flag) { /* 主循環(huán)正常處理業(yè)務(wù) */ } /* 退出前做資源清理、落日志 */ return 0; }volatile sig_atomic_t是標(biāo)準(zhǔn)推薦的信號標(biāo)志類型確保讀寫是原子的、且不會被編譯器優(yōu)化到寄存器里導(dǎo)致主循環(huán)看不到變化。這個信號置標(biāo)志位 主循環(huán)輪詢的模式在嵌入式里比任何花哨的做法都穩(wěn)。5.3 System V與POSIX共享內(nèi)存選型進(jìn)程間要傳大量數(shù)據(jù)尤其像攝像頭幀數(shù)據(jù)、傳感器批量采樣數(shù)據(jù)這種用管道就不合適了性能差、還要拷貝。共享內(nèi)存是正解多個進(jìn)程把同一塊物理內(nèi)存映射到自己的地址空間讀寫數(shù)據(jù)不需要經(jīng)過內(nèi)核拷貝是性能最高的IPC方式。System V共享內(nèi)存用起來偏繁瑣shmget創(chuàng)建/獲取、shmat映射、shmdt解除映射、shmctl控制。POSIX共享內(nèi)存用起來相對優(yōu)雅shm_open創(chuàng)建、mmap映射、munmap解除、shm_unlink刪除。嵌入式Linux一般兩者都支持我推薦用POSIX接口因為它和mmap的配合更統(tǒng)一接口也更少。代碼模板大概長這樣共享端和接收端配合/* 創(chuàng)建端 */ #include sys/mman.h #include fcntl.h #include unistd.h int shm_fd shm_open(/my_shm, O_CREAT | O_RDWR, 0666); ftruncate(shm_fd, 4096); void *addr mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0); /* 寫數(shù)據(jù)到addr指向的內(nèi)存 *//* 接收端 */ int shm_fd shm_open(/my_shm, O_RDWR, 0666); void *addr mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0); /* 從addr讀取數(shù)據(jù) */共享內(nèi)存的坑在于同步。多個進(jìn)程同時寫同一塊共享內(nèi)存必須配合信號量來保證互斥。System V信號量或者POSIX信號量都能干這事嵌入式里我常用POSIX有名信號量因為接口簡單、跨進(jìn)程好用#include semaphore.h sem_t *sem sem_open(/my_sem, O_CREAT, 0666, 1); sem_wait(sem); /* 臨界區(qū)讀寫共享內(nèi)存 */ sem_post(sem);還有一個我踩過的坑共享內(nèi)存的名字要以斜杠開頭比如/my_shm不能帶多余的斜杠。在嵌入式文件系統(tǒng)比較精簡的環(huán)境里/dev/shm可能沒掛載POSIX共享內(nèi)存會創(chuàng)建/打開失敗。遇到這類問題檢查一下/dev/shm是否存在以及權(quán)限是否正常。如果確實沒有也可以用老牌的System V接口或者干脆退回mmap某個普通文件匿名映射配合fork共享也算一種辦法但寫文件有持久化開銷一般我沒這么干。6. 進(jìn)程實戰(zhàn)一個嵌入式多進(jìn)程系統(tǒng)的完整設(shè)計6.1 一個多進(jìn)程采集系統(tǒng)的模塊劃分拿我之前做過的某工業(yè)數(shù)據(jù)采集網(wǎng)關(guān)來拆解硬件平臺是一塊ARM板內(nèi)存256MB跑精簡的嵌入式Linux。網(wǎng)關(guān)要完成的事情有采集多路串口傳感器的數(shù)據(jù)、把數(shù)據(jù)經(jīng)過網(wǎng)絡(luò)協(xié)議上報到中心服務(wù)器、在本地屏幕上顯示運行狀態(tài)、接收遠(yuǎn)程配置更新并生效。我沒有把這些功能寫成一個巨型進(jìn)程而是拆成了四個進(jìn)程采集進(jìn)程負(fù)責(zé)輪詢多路串口、解析協(xié)議把原始數(shù)據(jù)整理成標(biāo)準(zhǔn)格式寫入共享內(nèi)存。這個進(jìn)程最復(fù)雜牽涉串口狀態(tài)異常、通信超時等一堆判斷邏輯。上報進(jìn)程從共享內(nèi)存讀取數(shù)據(jù)通過TCP協(xié)議上報。它只關(guān)心數(shù)據(jù)有沒有新的不知道串口是什么、傳感器是什么協(xié)議。顯示進(jìn)程從共享內(nèi)存讀狀態(tài)更新本地屏幕。管理進(jìn)程接收遠(yuǎn)程配置通過信號和共享內(nèi)存把新的配置參數(shù)下發(fā)給采集進(jìn)程和上報進(jìn)程。進(jìn)程通信方式的選擇思路是采集進(jìn)程和上報進(jìn)程、顯示進(jìn)程之間大塊周期性數(shù)據(jù)用共享內(nèi)存。管理進(jìn)程發(fā)配置變更通知用信號SIGUSR1再配合共享內(nèi)存里的配置區(qū)。進(jìn)程崩潰恢復(fù)管理進(jìn)程周期性檢測其他進(jìn)程存活狀態(tài)發(fā)現(xiàn)異常直接拉起這個在嵌入式網(wǎng)關(guān)里就是心跳?；畹倪壿嫛９蚕韮?nèi)存設(shè)計概要#define DATA_SHM_SIZE (8 * 1024 * 1024) struct gateway_shm { sem_t data_sem; /* 數(shù)據(jù)區(qū)互斥信號量 */ unsigned int seq; /* 數(shù)據(jù)序號便于消費端判斷新數(shù)據(jù) */ size_t valid_len; /* 本次數(shù)據(jù)有效長度 */ unsigned char data[0]; /* 數(shù)據(jù)區(qū) */ };采集進(jìn)程寫數(shù)據(jù)前sem_wait寫完sem_post上報進(jìn)程讀取前也sem_wait/sem_post。seq序號是用來判斷有沒有新的一幀數(shù)據(jù)的續(xù)傳過程中如果seq沒變化上報進(jìn)程就不重復(fù)上報。這個設(shè)計在初期看起來簡單但實際運行非常穩(wěn)跑了幾個月基本沒出過問題。6.2 進(jìn)程同步與資源競爭的排查多進(jìn)程共享資源的核心問題就是競爭條件。嵌入式里最典型的競爭場景就兩個共享內(nèi)存讀寫競爭、日志文件多進(jìn)程寫入競爭。我在項目里排查過一個詭異的bug上報進(jìn)程偶爾上報的幀數(shù)據(jù)校驗不對但采集進(jìn)程自己檢查數(shù)據(jù)是完好的。查了一下午最后定位到是共享內(nèi)存的讀寫沒有加信號量保護(hù)。采集進(jìn)程在寫數(shù)據(jù)時上報進(jìn)程恰好也在讀讀到一半被覆蓋了導(dǎo)致半幀數(shù)據(jù)。修復(fù)方式就是在讀寫共享內(nèi)存前后加上互斥信號量。這個案例給我最深的教訓(xùn)是不要覺得數(shù)據(jù)量小、寫在瞬間完成就省信號量任何跨進(jìn)程共享的可變數(shù)據(jù)都必須有同步機制沒有例外。日志文件的競爭問題也很常見。多個進(jìn)程同時open同一個日志文件然后write由于O_APPEND模式下每次write是原子的所以不會丟行但多進(jìn)程交錯寫入會導(dǎo)致日志順序混亂、難以排查問題。我的做法是讓日志統(tǒng)一走一個獨立的日志進(jìn)程其他進(jìn)程通過管道或者socket把日志消息發(fā)給它由日志進(jìn)程串行落盤。這樣日志順序始終是對的排查問題時不用腦補。另外一個在嵌入式里經(jīng)常被忽略的競爭資源是同一個串口或者同一個外設(shè)。如果兩個進(jìn)程同時操作同一個串口數(shù)據(jù)就會互相干擾。解決方式就是通過一個設(shè)備管理進(jìn)程獨占這個串口其他進(jìn)程都用IPC給它發(fā)讀寫請求由它統(tǒng)一調(diào)度。這種單設(shè)備單進(jìn)程的架構(gòu)模式在嵌入式里非常實用。6.3 可復(fù)用的進(jìn)程啟動與監(jiān)控框架基于上面這個項目我沉淀了一套很輕量的進(jìn)程骨架后面做其他嵌入式產(chǎn)品也一直在復(fù)用。核心思路就是這個小流程統(tǒng)一封裝一個進(jìn)程主循環(huán)框架包含信號處理、日志初始化、看門狗上報。每個業(yè)務(wù)進(jìn)程都實現(xiàn)init()和loop()兩個函數(shù)主循環(huán)死循環(huán)調(diào)loop()。管理進(jìn)程通過一個pid文件或者共享內(nèi)存里各自對應(yīng)的存活標(biāo)志位來判斷進(jìn)程狀態(tài)。進(jìn)程崩潰時由系統(tǒng)啟動框架如supervisor或者自己寫個shell監(jiān)控腳本拉起來必要時配合硬件看門狗重啟整個系統(tǒng)。這種輕框架 多進(jìn)程的模式比一個進(jìn)程里寫幾百個線程要容易維護(hù)太多了。進(jìn)程掛了就拉起數(shù)據(jù)通過共享內(nèi)存交換模塊職責(zé)分明排錯不需要跨著整個系統(tǒng)猜。7. 常見問題與排查技巧7.1 嵌入式Linux進(jìn)程問題速查把我這些年遇到過的進(jìn)程相關(guān)問題整理成一張速查表順手就能當(dāng)排查手冊用現(xiàn)象原因排查方向系統(tǒng)進(jìn)程數(shù)持續(xù)增長子進(jìn)程退出未被回收僵尸堆積ps -ef查Z狀態(tài)檢查父進(jìn)程是否調(diào)用了waitpidfork返回失敗進(jìn)程數(shù)達(dá)到上限、內(nèi)存不足ulimit -u查看進(jìn)程限制free查內(nèi)存新進(jìn)程不干活但沒退出等某個IPC條件不滿足阻塞中cat /proc/PID/stack或strace看阻塞點共享內(nèi)存讀寫數(shù)據(jù)錯亂缺互斥信號量代碼審查檢查臨界區(qū)保護(hù)兩個進(jìn)程同時訪問串口沖突設(shè)備被多處打開查lsof /dev/ttyS*改成單進(jìn)程獨占程序退出后日志丟失exit時緩沖區(qū)未刷新或信號后函數(shù)不完整檢查是否用了_exit、是否優(yōu)雅關(guān)停SIGTERM殺掉進(jìn)程但資源沒釋放沒捕獲SIGTERM默認(rèn)直接死自己注冊SIGTERM處理做清理再退進(jìn)程變成孤兒后行為異常孤兒依賴了父進(jìn)程的資源守護(hù)進(jìn)程化要徹底別繼承終端和父進(jìn)程fd排查手段優(yōu)先用這幾個ps -ef # 總覽進(jìn)程狀態(tài) ps -o pid,ppid,stat,cmd -A # 看關(guān)注字段 top # 看CPU、內(nèi)存占用 cat /proc/PID/status # 看單進(jìn)程詳細(xì)狀態(tài) cat /proc/PID/wchan # 看進(jìn)程阻塞在內(nèi)核哪個函數(shù) strace -p PID # 跟蹤進(jìn)程的系統(tǒng)調(diào)用嵌入式板子上如果沒有strace可以臨時編譯一個靜態(tài)版放進(jìn)去這是我常用的辦法。strace對排查進(jìn)程卡住不動的問題幾乎是神器能看到它阻塞在哪個syscall上。7.2 實戰(zhàn)中容易忽視的細(xì)節(jié)與經(jīng)驗先聊文件描述符泄漏。一個進(jìn)程長期運行如果每次循環(huán)里打開文件或socket后忘了close文件描述符會慢慢漲到上限然后程序開始異常。排查方法很簡單看/proc/PID/fd目錄里的描述符合不合理、數(shù)量是否持續(xù)上漲。fd泄漏是嵌入式守護(hù)進(jìn)程最常見的隱形bug之一我建議在你的進(jìn)程骨架里定期統(tǒng)計fd數(shù)量并打日志。再聊環(huán)境變量的坑。用exec族時子進(jìn)程繼承父進(jìn)程的環(huán)境變量。但有些嵌入式庫在找不到某個環(huán)境變量時會靜默降級比如NFS、時區(qū)、語言相關(guān)的環(huán)境變量可能導(dǎo)致行為異常。排查時可以用env命令看當(dāng)前環(huán)境變量必要時在代碼里用setenv顯式設(shè)置。還有一個心得是關(guān)于信號與主循環(huán)的協(xié)作。我曾經(jīng)在一個進(jìn)程里用鬧鐘信號SIGALRM做定時采樣信號處理函數(shù)里直接調(diào)用了一個業(yè)務(wù)函數(shù)。后來采樣周期要求從100ms改成20ms驚喜發(fā)生了主循環(huán)邏輯被信號打斷的頻率變高了某些臨界區(qū)被插入執(zhí)行數(shù)據(jù)出現(xiàn)偶發(fā)不一致。最后改成信號只置標(biāo)志位主循環(huán)通過select或者epoll_wait帶超時來處理定時任務(wù)問題徹底消失?，F(xiàn)在我的代碼里信號處理函數(shù)里絕對不碰業(yè)務(wù)邏輯這已經(jīng)成了我的鐵律。線程與進(jìn)程混合使用時也要注意多線程進(jìn)程里fork子進(jìn)程里只保留調(diào)用fork的那個線程其他線程都沒了。如果子進(jìn)程要訪問那些線程持有的鎖可能直接死鎖。所以設(shè)計上盡量讓進(jìn)程和線程的邊界清晰不要搞大雜燴。嵌入式產(chǎn)品穩(wěn)定優(yōu)先能用多進(jìn)程劃分的模塊就不強行用多線程。最后講一個看門狗相關(guān)的經(jīng)驗。嵌入式Linux系統(tǒng)一般會用硬件看門狗或者軟件看門狗保證系統(tǒng)不徹底死掉。多進(jìn)程架構(gòu)里軟件看門狗的邏輯通常是一個監(jiān)控進(jìn)程周期性檢查各業(yè)務(wù)進(jìn)程的心跳心跳異常就重啟對應(yīng)進(jìn)程如果監(jiān)控進(jìn)程本身也不行了硬件看門狗在規(guī)定時間內(nèi)沒被喂狗整機復(fù)位。這個層級化的保活機制在多進(jìn)程架構(gòu)下實現(xiàn)起來非常自然也是一個進(jìn)程架構(gòu)相對線程架構(gòu)的突出優(yōu)勢。我曾經(jīng)在采集網(wǎng)關(guān)里把每個進(jìn)程的心跳寫進(jìn)共享內(nèi)存管理進(jìn)程每秒檢查一次連續(xù)三次心跳超時就果斷重啟對應(yīng)進(jìn)程實測整套系統(tǒng)連續(xù)運行數(shù)月沒有死透的情況。個人經(jīng)驗方面做進(jìn)程開發(fā)調(diào)試時代碼里多打日志、日志里帶上PID和時間戳是成本最低的排查手段。嵌入式上沒有IDE調(diào)試器那么方便很多時候就是靠日志定位問題。但日志也不能隨便打每個循環(huán)里打一堆反而干擾問題定位建議關(guān)鍵決策點打日志比如進(jìn)程啟動、退出、收到信號、寫共享內(nèi)存成功失敗。日志級別控制手段也要有線上跑release日志測試環(huán)境開debug日志。還有個容易翻車的點嵌入式系統(tǒng)有時區(qū)設(shè)置或者環(huán)境變量缺失導(dǎo)致進(jìn)程啟動失敗。如果一個進(jìn)程起不來先手動在終端里跑一下看它打印什么錯誤然后再去看啟動腳本哪里不對。很多啟動失敗其實是動態(tài)庫找不到ldd可以查依賴、配置文件路徑不對、或者權(quán)限不足跟進(jìn)程本身的邏輯沒什么關(guān)系。做嵌入式Linux進(jìn)程開發(fā)的過程說到底就是在并發(fā)和隔離這兩件事上做平衡。進(jìn)程給了你隔離的穩(wěn)定邊界但同時也把并發(fā)、通信、同步這些復(fù)雜度帶進(jìn)來了。你能把這些復(fù)雜度一個一個地控制住這個產(chǎn)品的穩(wěn)定性和可維護(hù)性就上來了。上面這些坑和經(jīng)驗都是我在真實項目里一步步踩出來的當(dāng)你自己摸著石頭過河時希望這篇內(nèi)容能幫你少走幾步彎路。