ไม่สามารถหยุดสคริปต์ทุบตีด้วย Ctrl + C

ฉันเขียนสคริปต์ทุบตีง่าย ๆ ด้วยวนสำหรับพิมพ์วันที่และ ping ไปยังเครื่องระยะไกล:

#!/bin/bash
while true; do
    #     *** DATE: Thu Sep 17 10:17:50 CEST 2015  ***
    echo -e "\n*** DATE:" `date` " ***";
    echo "********************************************"
    ping -c5 $1;
done

เมื่อฉันเรียกใช้จากเทอร์มินัลฉันไม่สามารถหยุดมันCtrl+Cได้ ดูเหมือนว่าจะส่ง^Cไปยังเทอร์มินัล แต่สคริปต์ไม่หยุด

MacAir:~ tomas$ ping-tester.bash www.google.com

*** DATE: Thu Sep 17 23:58:42 CEST 2015  ***
********************************************
PING www.google.com (216.58.211.228): 56 data bytes
64 bytes from 216.58.211.228: icmp_seq=0 ttl=55 time=39.195 ms
64 bytes from 216.58.211.228: icmp_seq=1 ttl=55 time=37.759 ms
^C                                                          <= That is Ctrl+C press
--- www.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 40.887/59.699/78.510/18.812 ms

*** DATE: Thu Sep 17 23:58:48 CEST 2015  ***
********************************************
PING www.google.com (216.58.211.196): 56 data bytes
64 bytes from 216.58.211.196: icmp_seq=0 ttl=55 time=37.460 ms
64 bytes from 216.58.211.196: icmp_seq=1 ttl=55 time=37.371 ms

ไม่ว่าฉันจะกดกี่ครั้งหรือเร็วแค่ไหนก็ตาม ฉันไม่สามารถหยุดมันได้
ทำแบบทดสอบและรับรู้ด้วยตัวเอง

เป็นวิธีแก้ปัญหาด้านฉันกำลังหยุดมันด้วยที่จะหยุดมันแล้วCtrl+Zkill %1

เกิดอะไรขึ้นที่นี่ด้วย^C?

สิ่งที่เกิดขึ้นคือการที่ทั้งสองbashและpingได้รับ SIGINT ( bashเป็นไม่โต้ตอบทั้งสองpingและการbashทำงานในกระบวนการกลุ่มเดียวกันซึ่งได้รับการสร้างขึ้นและตั้งเป็นกลุ่มกระบวนการเบื้องหน้าของสถานีโดยเปลือกโต้ตอบคุณวิ่งจากสคริปต์ที่)

อย่างไรก็ตามbashจัดการ SIGINT นั้นแบบอะซิงโครนัสเฉพาะหลังจากที่ออกคำสั่งที่รันอยู่ในปัจจุบัน bashออกจากเมื่อได้รับ SIGINT เท่านั้นหากคำสั่งที่รันอยู่ในปัจจุบันนั้นเสียชีวิตของ SIGINT (นั่นคือสถานะทางออกของมันบ่งชี้ว่า SIGINT นั้นถูกฆ่าแล้ว)

$ bash -c 'sh -c "trap exit\ 0 INT; sleep 10; :"; echo here'
^Chere

ข้างต้นbash, shและsleepได้รับ SIGINT เมื่อกด Ctrl-C แต่shออกได้ตามปกติด้วยรหัส 0 ทางออกเพื่อbashละเว้น SIGINT ซึ่งเป็นเหตุผลที่เราเห็น "ที่นี่"

pingอย่างน้อยหนึ่งตัวจาก iputils ก็เป็นแบบนั้น เมื่อถูกขัดจังหวะมันจะพิมพ์สถิติและออกด้วยสถานะทางออก 0 หรือ 1 ขึ้นอยู่กับว่ามีการตอบปิงหรือไม่ ดังนั้นเมื่อคุณกด Ctrl-C ขณะที่pingกำลังทำงานอยู่โปรดbashทราบว่าคุณได้กดCtrl-Cตัวจัดการ SIGINT แต่เนื่องจากการpingออกตามปกติbashจะไม่ออก

หากคุณเพิ่ม a sleep 1ในลูปนั้นและกดCtrl-Cขณะที่sleepกำลังทำงานเนื่องจากsleepไม่มีตัวจัดการพิเศษบน SIGINT มันจะตายและรายงานbashว่ามันตายจาก SIGINT และในกรณีbashนั้นจะออก (จริง ๆ แล้วจะฆ่าตัวเองด้วย SIGINT เพื่อ เพื่อรายงานการหยุดชะงักของผู้ปกครอง)

สำหรับสาเหตุที่เป็นbashเช่นนั้นฉันไม่แน่ใจและฉันทราบว่าพฤติกรรมนั้นไม่ได้กำหนดไว้ล่วงหน้าเสมอไป ฉันเพิ่งถามคำถามเกี่ยวกับbashรายชื่อรับจดหมายข่าวเพื่อการพัฒนา ( อัปเดต : @Jilles ได้ย้ำเหตุผลในคำตอบของเขาไว้แล้ว)

เชลล์อื่น ๆ ที่ฉันพบว่ามีพฤติกรรมคล้ายกันคือ ksh93 (อัปเดตตามที่ @Jilles พูดถึงเช่น FreeBSDsh ) ดูเหมือนว่า SIGINT จะถูกเพิกเฉยอย่างชัดเจน และksh93ออกเมื่อใดก็ตามที่คำสั่งถูกฆ่าโดย SIGINT

คุณได้รับพฤติกรรมเช่นเดียวกับbashข้างต้น แต่ยัง:

ksh -c 'sh -c "kill -INT \$\$"; echo test'

ไม่ส่งออก "ทดสอบ" นั่นคือมันจะออก (โดยการฆ่าตัวเองพร้อมกับ SIGINT ที่นั่น) หากคำสั่งที่กำลังรอการตายของ SIGINT แม้ว่ามันจะไม่ได้รับ SIGINT นั้นก็ตาม

การหลีกเลี่ยงจะเพิ่ม:

trap 'exit 130' INT

ที่ด้านบนของสคริปต์เพื่อบังคับbashให้ออกเมื่อได้รับ SIGINT (โปรดทราบว่าในกรณีใด ๆ SIGINT จะไม่ถูกประมวลผลแบบซิงโครนัสเฉพาะหลังจากที่คำสั่งที่รันอยู่ในปัจจุบันได้ออกไปแล้ว)

ตามหลักการแล้วเราต้องการรายงานไปยังผู้ปกครองของเราว่าเราเสียชีวิตจาก SIGINT (ดังนั้นหากเป็นbashสคริปต์อื่นเช่นbashสคริปต์นั้นก็จะถูกขัดจังหวะด้วย) การทำแบบexit 130นี้ไม่เหมือนกับการตายของ SIGINT (แม้ว่ากระสุนบางตัวจะตั้งค่า$?เป็นค่าเดียวกันสำหรับทั้งสองกรณี) แต่ก็มักจะใช้เพื่อรายงานการตายโดย SIGINT (ในระบบที่ SIGINT เป็น 2 ซึ่งมากที่สุด)

อย่างไรก็ตามสำหรับbash, ksh93หรือ FreeBSD shที่ไม่ได้ทำงาน สถานะทางออก 130 รายการนั้นไม่ถือเป็นความตายโดย SIGINT และสคริปต์หลักจะไม่ยกเลิกที่นั่น

ดังนั้นทางเลือกที่ดีกว่าน่าจะเป็นการฆ่าตัวเราเองด้วย SIGINT เมื่อได้รับ SIGINT:

trap '
  trap - INT # restore default INT handler
  kill -s INT "$$"
' INT

คำอธิบายก็คือว่าการดำเนินการทุบตี WCE (รอและออกจากสหกรณ์) สำหรับ SIGINT และ SIGQUIT ต่อhttp://www.cons.org/cracauer/sigint.html นั่นหมายความว่าถ้า bash ได้รับ SIGINT หรือ SIGQUIT ในขณะที่รอให้กระบวนการออกมันจะรอจนกว่ากระบวนการจะออกและจะออกจากตัวเองหากกระบวนการออกจากสัญญาณนั้น สิ่งนี้ทำให้มั่นใจได้ว่าโปรแกรมที่ใช้ SIGINT หรือ SIGQUIT ในส่วนต่อประสานผู้ใช้จะทำงานได้ตามที่คาดหวังไว้ (หากสัญญาณไม่ได้ทำให้โปรแกรมหยุดทำงานสคริปต์จะทำงานต่อตามปกติ)

ข้อเสียปรากฏขึ้นพร้อมกับโปรแกรมที่จับ SIGINT หรือ SIGQUIT แต่แล้วก็ยกเลิกเพราะมันใช้การออกปกติ () แทนการส่งสัญญาณไปยังตัวเอง อาจไม่สามารถขัดจังหวะสคริปต์ที่เรียกโปรแกรมดังกล่าวได้ ฉันคิดว่าการแก้ไขที่แท้จริงมีอยู่ในโปรแกรมเช่น ping และ ping6

ksh93 และ FreeBSD's / bin / sh นั้นมีพฤติกรรมที่คล้ายกัน แต่ไม่สามารถใช้งานได้โดยเชลล์ส่วนใหญ่

ในขณะที่คุณคาดการณ์สิ่งนี้เกิดจาก SIGINT ถูกส่งไปยังกระบวนการรองและเชลล์ดำเนินการต่อหลังจากกระบวนการนั้นจบการทำงาน

เพื่อจัดการสิ่งนี้ในวิธีที่ดีกว่าคุณสามารถตรวจสอบสถานะการออกของคำสั่งที่กำลังทำงานอยู่ โค้ดส่งคืน Unix เข้ารหัสทั้งเมธอดที่ออกจากกระบวนการ (การเรียกระบบหรือสัญญาณ) และค่าใดที่ถูกส่งไปยังexit()หรือสัญญาณใดที่ยกเลิกกระบวนการ ทั้งหมดนี้ค่อนข้างซับซ้อน แต่วิธีที่เร็วที่สุดในการใช้คือรู้ว่ากระบวนการที่ถูกยกเลิกโดยสัญญาณจะมีรหัสส่งคืนที่ไม่เป็นศูนย์ ดังนั้นหากคุณตรวจสอบรหัสส่งคืนในสคริปต์ของคุณคุณสามารถออกจากตัวคุณเองได้หากกระบวนการลูกถูกยุติลงทำให้ไม่จำเป็นต้องใช้ความไม่สะดวกเช่นการsleepโทรที่ไม่จำเป็น วิธีที่รวดเร็วในการทำเช่นนี้ตลอดทั้งสคริปต์ของคุณคือการใช้งานset -eแม้ว่าอาจต้องใช้การปรับแต่งเล็กน้อยสำหรับคำสั่งที่สถานะการออกนั้นเป็นค่าที่ไม่ใช่ศูนย์

เทอร์มินัลจะสังเกตเห็น control-c และส่งINTสัญญาณไปยังกลุ่มกระบวนการพื้นหน้าซึ่งในที่นี้จะมีเชลล์เนื่องจากpingไม่ได้สร้างกลุ่มกระบวนการพื้นหน้าใหม่ INTนี้เป็นเรื่องง่ายในการตรวจสอบโดยการวางกับดัก

#! /bin/bash
trap 'echo oh, I am slain; exit' INT
while true; do
  ping -c5 127.0.0.1
done

หากคำสั่งที่กำลังรันได้สร้างกลุ่มกระบวนการพื้นหน้าใหม่ตัวควบคุม -c จะไปที่กลุ่มกระบวนการนั้นไม่ใช่ไปที่เชลล์ ในกรณีนี้เชลล์จะต้องตรวจสอบรหัสทางออกเนื่องจากจะไม่ได้รับสัญญาณจากเทอร์มินัล

( INTการจัดการในเปลือกหอยจะมีความซับซ้อน fabulously โดยวิธีการที่เป็นเปลือกบางครั้งความต้องการที่จะไม่สนใจสัญญาณและบางครั้งไม่มาดำน้ำถ้าอยากรู้อยากเห็นหรือไตร่ตรอง:. tail -f /etc/passwd; echo foo)

ฉันพยายามเพิ่ม a sleep 1bash script และ bang! ตอนนี้ฉันสามารถที่จะหยุดมันด้วยสอง
Ctrl+C

เมื่อมีการกดCtrl+Cเป็นSIGINTสัญญาณที่ถูกส่งไปยังขั้นตอนการดำเนินการในขณะนี้ซึ่งคำสั่งถูกเรียกใช้ภายในวง จากนั้นกระบวนการย่อยจะดำเนินการคำสั่งถัดไปในลูปซึ่งจะเริ่มต้นกระบวนการอื่นต่อไป เพื่อให้สามารถหยุดสคริปต์ได้จำเป็นต้องส่งSIGINTสัญญาณสองสัญญาณสัญญาณหนึ่งเพื่อขัดจังหวะคำสั่งปัจจุบันในการทำงานและอีกสัญญาณหนึ่งเพื่อขัดจังหวะกระบวนการsubshell

ในสคริปต์ที่ไม่มีการsleepเรียกการกดCtrl+Cอย่างรวดเร็วและหลายครั้งดูเหมือนจะไม่ทำงานและไม่สามารถออกจากลูปได้ ฉันเดาว่าการกดสองครั้งไม่เร็วพอที่จะทำให้มันเกิดขึ้นในช่วงเวลาที่เหมาะสมระหว่างการหยุดชะงักของกระบวนการที่ดำเนินการในปัจจุบันและการเริ่มต้นของกระบวนการถัดไป ทุกคนCtrl+Cกดจะส่งSIGINTไปยังกระบวนการดำเนินการภายในห่วง แต่ไม่ไปsubshell

ในสคริปต์ด้วยsleep 1การเรียกนี้จะระงับการดำเนินการเป็นเวลาหนึ่งวินาทีและเมื่อถูกขัดจังหวะด้วยการแรกCtrl+C(แรกSIGINT), subshellจะใช้เวลามากขึ้นในการดำเนินการคำสั่งต่อไป ดังนั้นตอนนี้วินาทีที่Ctrl+CสองSIGINTจะไปที่subshellและการประมวลผลสคริปต์จะสิ้นสุดลง

ลองสิ่งนี้:

#!/bin/bash
while true; do
   echo "Ctrl-c works during sleep 5"
   sleep 5
   echo "But not during ping -c 5"
   ping -c 5 127.0.0.1
done

ตอนนี้เปลี่ยนบรรทัดแรกเป็น:

#!/bin/sh

และลองอีกครั้ง - ดูว่าการ ping ขัดจังหวะหรือไม่

pgrep -f process_name > any_file_name
sed -i 's/^/kill /' any_file_name
chmod 777 any_file_name
./any_file_name

ตัวอย่างเช่นpgrep -f firefoxจะ grep PID ของการทำงานfirefoxและจะบันทึก PID any_file_nameนี้เพื่อไฟล์ที่เรียกว่า คำสั่ง 'sed' จะเพิ่มหมายเลขkillเริ่มต้นของหมายเลข PID ในไฟล์ 'any_file_name' บรรทัดที่สามจะany_file_nameเรียกใช้ไฟล์ได้ ตอนนี้บรรทัดany_file_nameถัดไปจะฆ่า PID ที่มีอยู่ในไฟล์ เขียนข้างต้นสี่บรรทัดในไฟล์และรันไฟล์ที่สามารถทำ-Control Cทำงานได้ดีอย่างแน่นอนสำหรับฉัน

หากใครสนใจแก้ไขbashคุณสมบัตินี้และไม่ได้ยึดติดกับปรัชญามากนักนี่เป็นข้อเสนอ:

อย่าเรียกใช้คำสั่งที่มีปัญหาโดยตรง แต่จากเสื้อคลุมที่) รอให้มันยุติข) ไม่ยุ่งกับสัญญาณและ C) จะไม่ใช้กลไก WCE ตัวเอง SIGINTแต่ก็ตายเมื่อได้รับ

wrapper นั้นสามารถใช้กับawk+ system()function ได้

$ while true; do awk 'BEGIN{system("ping -c5 localhost")}'; done
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.082 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.087 ms
^C
--- localhost ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1022ms
rtt min/avg/max/mdev = 0.082/0.084/0.087/0.009 ms
[3]-  Terminated              ping -c5 localhost

ใส่ในสคริปต์เช่น OP ของ:

#!/bin/bash
while true; do
        echo -e "\n*** DATE:" `date` " ***";
        echo "********************************************"
        awk 'BEGIN{system(ARGV[1])}' "ping -c5 ${1-localhost}"
done

คุณเป็นเหยื่อของข้อผิดพลาดที่รู้จักกันดี Bash ทำหน้าที่ควบคุมงานของสคริปต์ซึ่งเป็นข้อผิดพลาด

สิ่งที่เกิดขึ้นคือการทุบตีรันโปรแกรมภายนอกในกลุ่มกระบวนการที่แตกต่างจากที่ใช้สำหรับสคริปต์เอง เนื่องจาก TTG processgroup ถูกตั้งค่าเป็น processgroup ของกระบวนการโฟร์กราวน์ปัจจุบันกระบวนการโฟร์กราวน์นี้จะถูกฆ่าและลูปในเชลล์สคริปต์จะดำเนินต่อไป

ในการตรวจสอบ: ดึงและรวบรวมเชลล์เป้าหมายล่าสุดที่ใช้ pgrp (1) เป็นโปรแกรมในตัวจากนั้นเพิ่ม / bin / sleep 100 (หรือ / usr / bin / sleep ขึ้นอยู่กับแพลตฟอร์มของคุณ) ลงในลูปสคริปต์แล้วเริ่ม บอร์นเชลล์ หลังจากที่คุณใช้ ps (1) เพื่อรับ ID กระบวนการสำหรับคำสั่ง sleep และ bash ที่รันสคริปต์ให้เรียกpgrp <pid>และแทนที่ "<pid>" ด้วย ID กระบวนการของ sleep และ bash ที่รันสคริปต์ คุณจะเห็นรหัสกลุ่มกระบวนการที่แตกต่างกัน ตอนนี้เรียกสิ่งที่ชอบpgrp < /dev/pts/7(แทนที่ชื่อ tty ด้วย tty ที่ใช้โดยสคริปต์) เพื่อรับกลุ่มกระบวนการ tty ปัจจุบัน กลุ่มกระบวนการ TTY เท่ากับกลุ่มกระบวนการของคำสั่ง sleep

วิธีแก้ไข: ใช้เชลล์ตัวอื่น

แหล่ง Bourne Shell ล่าสุดอยู่ในชุดเครื่องมือ schily ของฉันซึ่งคุณสามารถหาได้ที่นี่:

http://sourceforge.net/projects/schilytools/files/