項目中在使用kube-keepalived-vip時遇到了keepalived相關的Bug, 本來計劃測試最新版的keepalived看是否存在一樣的問題. 在將keepalived升級到當前最新版本v2.0.7以後發現每次執行kubectl delete pod <kube-keepalived-vip pod>
都會出現segfault的內核錯誤, 且較大機率會連帶出現keepalived的殭屍進程, 但對比發現經過手動執行kill -9
結束keepalived進程卻沒有這個問題. 翻了一下runc的代碼發現kubectl delete
實際上(默認狀況)是經過發給進程一個SIGTERM的信號讓其退出, 這就是爲何手動執行kill -9
沒有出現一樣的問題. 這裏索性整理了一下與結束進程相關的信號的區別和聯繫.html
- 信號是軟件中斷, 不少比較重要的應用程序都須要處理信號. 信號提供了一種處理異步事件的方法. 例如, 終端用於鍵入中斷健, 會經過信號機制中止一個程序, 或及早終止管道中的下一個程序.
- UNIX系統的早期版本就已經提供信號機制, 可是這些系統(V7)所提供的信號模型並不可靠. 信號可能丟失, 而且在執行臨界區代碼時, 進程很難關閉所選擇的信號. 4.3BSD和SVR3對信號模型都作了修改, 增長了可靠信號機制. 可是Berkeley和AT&T所作的更改之間並不兼容. 幸運的是, POSIX.1對可靠信號例程進行了標準化.
- 在Linux系統當中可直接經過
kill
命令加-l
參數列出全部的信號, 主要依據頭文件/usr/include/linux/signal.h
.- 能夠看到全部的信號都包含一個正整數序號(序號0有特殊用途)和一個以SIG開頭的簡稱
[root@10-10-88-192 ~]# kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX [root@10-10-88-192 ~]#
經過kill -l
能夠看到操做系統總共提供了64種信號, 這裏只列舉了與結束進程相關的幾種信號, 分別是信號序號爲一、二、三、九、15的SIGHUP、SIGINT、SIGKILL、SIGTERMnode
- 若是終端接口檢測到一個鏈接斷開, 則將此信號送給與該終端相關的控制進程. (與之相關的命令爲
nohup
)- 若是終端會話首進程終止, 也產生此信號. 在這種狀況下, 此信號送給前臺進程組中的每個進程.
- 一般用此信號通知守護進程再次讀取它們的配置文件. 選用SIGHUP的理由是, 守護進程不會有控制終端, 一般毫不會接收到這種信號.
- 這也是
kube-keepalived-vip
當中reloadkeepalived.conf
的方式
kill -1 <pid>
- 用戶按下中斷健(通常採用DELETE或Ctrl+C)時, 終端驅動程序產生此信號併發送至前臺進程組中的每個進程.
- 當一個進程組在運行時失控, 特別是當進程正在屏幕上產生大量不須要的輸出時, 經常使用此信號終止.
kill -2 <pid>
- 當用戶在終端上按退出鍵(通常採用Ctrl + ), 中斷驅動程序產生此信號, 併發送給前臺進程組中的全部進程.
- 此信號不只終止前臺進程組(如SIGINT), 同時將產生一個core文件(關於如何查看core文件, 見另外一片博文《如何查看core文件》).
- 設計的初衷爲以較溫和地方式退出程序, 讓程序在退出前能夠清理一些臨時文件或者作別的處理, 但建議最好很差清理臨時文件, 方便gdb配合core文件進行Debug.
kill -3 <pid>
- 強制當即結束進程, 相較於其餘信號, SIGKILL信號不可以被進程捕獲, 也不可以被忽略, 所以老是可以結束進程(若是不行, 那必定是操做系統的Bug).
- 不可以阻塞該信號
- 使用該信號必定要想清楚後果
kill -9 <pid>
kill
命令默認發送的終止信號.- 該信號可由應用程序捕獲, 故使用SIGTERM也讓程序有機會在退出以前作好清理工做, 從而優雅地終止.
kill -15 <pid>
不少時候不少莫名其妙的問題或者Bug都是由於咱們對一些細節的不理解或者掌握的不夠透徹, 就好比結束一個進程就有這麼多種方式, 你是否每一種方式都可以說清楚呢? 基礎是否夯實正是從平常工做的小事積累和體現出來.linux