關(guān)于這個(gè)shell為什么沒有停止

sncchen

找到一篇文章講解的不錯(cuò)：
https://  blog.robotshell.org/2012/necessary-details-about-signal-trap-in-shell

他也提到了樓主說(shuō)的文檔：
http://  mywiki.wooledge.org/SignalTrap

梳理下原因：

1、

Bash 等終端的默認(rèn)行為是這樣的：當(dāng)按下 CTRL-C 之后，它會(huì)向當(dāng)前的整個(gè)進(jìn)程組發(fā)出 SIGINT 信號(hào)。而 sleep 是由當(dāng)前腳本調(diào)用的，是這個(gè)腳本的子進(jìn)程，默認(rèn)是在同一個(gè)進(jìn)程組的，所以也會(huì)收到 SIGINT 并停止執(zhí)行

2、

這篇文檔給了我們一個(gè)更準(zhǔn)確的說(shuō)明——如果當(dāng)前正有一個(gè)外部命令在前臺(tái)執(zhí)行，那么 trap 會(huì)等待當(dāng)前命令結(jié)束以后再處理信號(hào)隊(duì)列中的信號(hào)。

3、

On most operating systems, ping is an example of a misbehaving process. It traps SIGINT in order to display a summary at the end, before exiting. But it fails to kill itself with SIGINT, and so the calling shell does not know that it should abort as well

這個(gè)問題挺有趣兒的，學(xué)習(xí)了。

homerzhou

還是有一個(gè)小的疑惑，那篇文檔中提到  “如果當(dāng)前正有一個(gè)外部命令在前臺(tái)執(zhí)行，那么 trap 會(huì)等待當(dāng)前命令結(jié)束以后再處理信號(hào)隊(duì)列中的信號(hào)�！�  ，不管怎么樣./test.sh 還是會(huì)收到SIGINT的信號(hào)，即使需要等到ping結(jié)束之后，那為什么這個(gè)時(shí)候收到SIGINT信號(hào)就沒有停止呢，
“But it fails to kill itself with SIGINT, and so the calling shell does not know that it should abort as well”
我是這么理解這句話的意思的，當(dāng)按ctrl +c 時(shí)，如果子進(jìn)程ping沒有因?yàn)镾IGINT信號(hào)退出，那么./test.sh不知道子進(jìn)程ping是由于SIGINT退出的，它認(rèn)為ping是正常退出的，這時(shí)./test.sh對(duì)SIGINT就會(huì)是默認(rèn)不處理，不知道這么理解對(duì)不對(duì)，要是確實(shí)是這樣的話，有鏈接可以共享嗎？
回復(fù) 11# sncchen


   

yjh777

我知道原因了，bash的 SIGINT 處理邏輯如下:
    判斷是否還有活著的子進(jìn)程，如果沒有了就退出，如果還有就忽略;

ping的特殊性在于，它收到信號(hào)后，先做一些需要一定時(shí)間的操作 然后再退出
    如果這個(gè)退出在bash處理SIGINT之前，bash就不會(huì)退出。


下面是我寫的一個(gè)用于測(cè)試的例子，三種情況:
    1) 如果把 sub.sh 里面那個(gè)usleep 時(shí)間設(shè)置的足夠長(zhǎng)，shell就永遠(yuǎn)不會(huì)退出
    2) 如果把 usleep 和 上面的echo去掉，快速按幾次Ctr+C 就可以讓shell退出，因?yàn)楦缸舆M(jìn)程處理SIGINT的耗時(shí)相當(dāng)
    3) 如果sub.sh不去trap SIGINT的話，系統(tǒng)默認(rèn)的SIGINT處理是最快的，
          所以子進(jìn)程總是在shell處理SIGINT時(shí)就死光了，所以shell就一次Ctr+C 就保證退出了

1. jiyin@dhcp-12-137:~$ cat kkk.sh
   
2. 
   
3. while :; do
   
4.                 ./sub.sh
   
5. done
   
6. jiyin@dhcp-12-137:~$ cat sub.sh
   
7. 
   
8. sigproc() {
   
9.         echo "$@" >>sig.log
   
10.         usleep 100000
    
11.         exit
    
12. }
    
13. 
    
14. >sig.log
    
15. trap sigproc SIGINT SIGTERM
    
16. 
    
17. echo "I am a sub process of kkk.sh $"
    
18. sleep 10
    

復(fù)制代碼

@homerzhou

homerzhou

有道理！回復(fù) 13# yjh777


   

millerix

主要是因?yàn)閎ash 腳本作為父進(jìn)程處于waitpid時(shí)，會(huì)檢查子進(jìn)程是如何退出的。 如果是調(diào)用exit退出的， 父進(jìn)程不退出，bash 腳本繼續(xù)運(yùn)行。 如果是因?yàn)槭盏絊IGINT信號(hào)后做默認(rèn)處理退出的（也就是不捕獲該信號(hào)），父進(jìn)程退出，bash 腳本終止執(zhí)行。

ping代碼中捕獲了SIGINT信號(hào)，并安裝了信號(hào)處理函數(shù)， 該信號(hào)處理函數(shù)打印統(tǒng)計(jì)信息， 然后正常返回，ping隨后也正常退出了。 bash發(fā)現(xiàn)子進(jìn)程退出，但是不是因?yàn)镾IGINT默認(rèn)處理退出的，所以 父進(jìn)程并不退出， 而是繼續(xù)執(zhí)行。