最近在定位用戶態的一個進程kerneld進程意外掛死的情況，但無法進行復現，只從代碼的角度分析掛死原因，
感覺應該是意外接收了某個信號，處理信號時exit了，，要麼就是normal內存塊中剩餘內存大於low小於Middle，
造成內核釋放用戶態佔用過多的內存的進程，，但資料上說，當剩餘內存小於low時就觸發了oom-killer，，
然後對對用戶態進程進行大規模殺害，直到剩餘內存大於high。
p.s kerneld 進程在燒寫鏡像時會佔用大量的內存。
此外該進程的SIGHUP信號處理函數中有exit 0， 所以學習一下後臺進程能收到和處理怎樣的信號。
注意：以下內容爲轉載的，原文鏈接爲，http://blog.csdn.net/hbhhww/article/details/6800772
此處僅做記錄學習。
當我們需要在遠程測試環境中運行諸如壓力測試等需要後臺運行的程序，但是當你關閉了遠程登錄的窗體時，
卻意外的也關閉了你的後臺程序。這個問題的原因是：後臺執行的進程，其父進程還是當前終端shell的進程，
而一旦父進程退出，則會發送hangup信號給所有子進程，子進程收到hangup以後也會退出。
你可以使用下面的命令解決這個問題nohup ./test.sh &
SIGUP
unix中進程組織結構爲 session 包含一個前臺進程組及一個或多個後臺進程組，一個進程組包含多個進程。
一個session可能會有一個session首進程，而一個session首進程可能會有一個控制終端。
一個進程組可能會有一個進程組首進程。進程組首進程的進程ID與該進程組ID相等。
這兒是可能會有，在一定情況之下是沒有的。
與終端交互的進程是前臺進程，否則便是後臺進程
SIGHUP會在以下3種情況下被髮送給相應的進程：
1、終端關閉時，該信號被髮送到session首進程以及作爲job提交的進程（即用 & 符號提交的進程）
2、session首進程退出時，該信號被髮送到該session中的前臺進程組中的每一個進程
3、若夫進程退出導致進程組成爲孤兒進程組，且該進程組中有進程處於停止狀態（收到SIGSTOP或SIGTSTP信號），
該信號會被髮送到該進程組中的每一個進程。
系統對SIGHUP信號的默認處理是終止收到該信號的進程。所以若程序中沒有捕捉該信號，當收到該信號時，進程就會退出
