今天碰到一個SIGHUP問題，再復習一遍：
有些信號的默認處理方式為“終止+core”，這里的core表示，進程終止時，會在進程的當前工作目錄生產一個core文件，該文件是進程終止時的內存快照，以便以后供debugger調試用。
以下情況不會生產core文件：
（1）為程序設置了set-user-ID並且用戶不是程序的所有者；
（2）為程序設置了set-group-ID並且用戶不是程序的組所有者；
（3）進程在當前工作目錄下面沒有寫權限；
（4）當前工作目錄下已有core文件且進程對該core文件沒有寫權限；
（5）core文件過大。
各種信號產生條件和默認處理方式描述如下：
SIGABRT 默認處理方式：終止+core；當程序調用abort函數時，會產生該信號。程序異常終止。
SIGALRM 默認處理方式：終止；當由alarm或setitimer函數設置的定時器超時時，會產生該信號。
SIGBUS 默認處理方式：終止+core；經常因為內存錯誤產生該信號。
SIGCHLD 默認處理方式：忽略；當進程terminate或stopped的時候，該信號會發送給父進程。如果父進程需要知道子進程什么時候終止，父進程必須捕獲該信號。通常在該信號的捕獲函數中調用wait或waitpid獲取子進程的pid和終止狀態。
SIGCONT 默認處理方式：忽略/繼續；作業控制命令進程繼續執行時，該信號發送給進程。如果進程之前已被停止，則該信號的默認處理方式是繼續進程的執行；否則，忽略該信號。
SIGFPE 默認處理方式：終止+core；當發生算術錯誤（如：除零，溢出等）時，產生該信號。
SIGHUP 默認處理方式：終止；當終端界面檢測到連接斷開時，內核向與控制終端的session leader進程發送該信號（當且僅當終端的CLOCAL標識位沒有被設置時，才會發送該信號）。接收信號的session leader可能是后台進程，這與普通終端產生的信號不同，普通終端信號接收者是前台進程組。另外，當控制終端的session leader終止時，SIGHUP信號會發送到前台進程組。因為守護進程沒有控制終端，通常不應該接收該信號的，所以這個信號常常被用作守護進程重新讀取配置文件的信號。
SIGILL 默認處理方式：終止；當處理器執行了非法指令時，產生該信號。
SIGINT 默認處理方式：終止；當向終端輸入終端鍵（Control+C或DELETE）時，終端產生SIGINT信號。該信號被發送到前台進程組。通常用來終止已運行的進程。
SIGIO 默認處理方式：終止/忽略；該信號用來提供異步IO模式。當有IO可用時，產生該信號通知進程。
SIGKILL 默認處理方式：終止；該信號給超級用戶提供了終止任何進程的能力，通常通過kill函數或命令。該信號不能夠被忽略或捕獲。
SIGPIPE 默認處理方式：終止；當向已經關閉讀者的管道寫數據時，會產生該信號。同樣向未連接的SOCK_STREAM類型的socket寫數據時，也會產生該信號。
SIGPOLL 默認處理方式：終止；當指定的事件發生在可選擇的設備上時，產生該信號。
SIGPROF 默認處理方式：終止；由setitimer設置的間隔定時器超時會產生該信號。
SIGPWR 默認處理方式：終止；當系統有UPS（Uninterruptible Power Supply，即電池）時，斷電后使用電池，當電池電量低時，會產生該信號通知進程在1530秒內關閉。
SIGQUIT 默認處理方式：終止+core；當輸入退出鍵（Control+\）時，終端將會產生SIGQUIT信號，該信號被傳送到前台進程組。
SIGSEGV 默認處理方式：終止+core；非法內存引用時，產生該信號。
SIGSTOP 默認處理方式：停止進程；作業控制信號，用來停止進程。該信號不能被忽略或捕獲。
SIGSYS 默認處理方式：終止+core；非法系統調用時，產生該信號。
SIGTERM 默認處理方式：終止；kill函數默認發送的信號，用來終止進程。
SIGTRAP 默認處理方式：終止+core；系統定義的硬件錯誤。通常，在遇到調試斷點時，將控制權傳遞給debugger。
SIGTSTP 默認處理方式：停止進程；當輸入掛起鍵（Control+Z）時，終端產生該（交互式停止）信號停止進程。該信號被發送給前台進程組。
SIGTTIN 默認處理方式：停止進程；當后台進程組中的進程要求從控制終端讀取數據時，會產生該信號。有兩個例外情況：1、要求讀數據的后台進程忽略或阻塞了該信號，2、進程所屬進程組是“孤兒”。在這兩種情況下，不會產生該信號，否則，read會錯誤返回，並將errno設置為EIO。
SIGTTOU 默認處理方式：停止進程；當后台進程組中的進程要求寫數據到控制終端時，會產生該信號。后台進程可以被允許寫數據到控制終端。當不允許后台進程寫數據到控制終端時，write會錯誤返回，並將errno設置為EIO。到有兩個例外情況：1、要求寫數據的后台進程忽略或阻塞了該信號，2、進程所屬進程組是“孤兒”。在這兩種情況下，不會產生該信號。
SIGURG 默認處理方式：忽略；當網絡連接（Socket）接收到帶外數據（out-of-band data）時，會產生該信號。
SIGUSR1 默認處理方式：終止；用戶自定義的信號。
SIGUSR2 默認處理方式：終止；用戶自定義的信號。
SIGVTALRM 默認處理方式：終止；由setitimer設置的虛擬定時器超時時，產生該信號。
SIGXCPU 默認處理方式：終止+core/忽略；進程超過了CPU的軟限制時，產生該信號。
SIGXFSZ 默認處理方式：終止+core/忽略；進程超過了文件大小的軟限制時，產生該信號。
原因，有人用ruby的telnet模塊整了個windows端的自動測試，腳本沒執行完就logout了導致有些程序
總莫名奇妙死掉； 可是並不是所有調用都出題，好像只有最后一個調用除了問題，而且telnet.cmd("script")
應該是阻塞型的啊，怎么腳本沒執行完logout就執行了，太TMD奇怪了； 可能是腳本有問題吧，下周
檢查一下腳本代碼。
require 'net/telnet'
# 連接到遠程主機 foobar
telnet = Net::Telnet.new("Host" => "foobar") {|c| print c}
# 登陸
telnet.login("your name", "your password") {|c| print c}
# 登陸后等待提示
telnet.cmd("ls") {|c| print c}
# 執行命令后等待提示
# 稍復雜的例子
telnet.cmd("sleep 5 && echo foobar &") {|c| print c}
STDOUT.flush # <- 若沒有這句的話，是很難看出程序已經運行到這里的
# 等待前面命令的輸出
telnet.waitfor(/foobar\Z/) {|c| print c}
# 結束登陸會話
telnet.cmd("exit") {|c| print c}
telnet.close