Không thể dừng tập lệnh bash bằng Ctrl + C

Tôi đã viết một tập lệnh bash đơn giản với một vòng lặp để in ngày và ping đến một máy từ xa:

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

Khi tôi chạy nó từ một thiết bị đầu cuối, tôi không thể dừng nó với Ctrl+C. Có vẻ như nó gửi ^Cthiết bị đầu cuối, nhưng kịch bản không dừng lại.

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

Không có vấn đề bao nhiêu lần tôi nhấn nó hoặc tôi làm nó nhanh như thế nào. Tôi không thể ngăn chặn nó.
Làm bài kiểm tra và nhận ra bởi chính mình.

Là một giải pháp phụ, tôi dừng nó lại Ctrl+Z, rồi dừng lại và sau đó kill %1.

Chính xác thì chuyện gì đang xảy ra ở đây ^C?

Điều gì xảy ra cả bashvà pingnhận được SIGINT ( bashlà không tương tác, cả hai pingvà bashchạy trong nhóm quá trình tương tự đã được tạo ra và thiết lập như nhóm quá trình foreground của thiết bị đầu cuối bằng vỏ tương tác bạn chạy mà kịch bản từ).

Tuy nhiên, bashxử lý SIGINT không đồng bộ, chỉ sau khi lệnh hiện đang chạy đã thoát. bashchỉ thoát khi nhận được SIGINT đó nếu lệnh hiện đang chạy bị chết của SIGINT (nghĩa là trạng thái thoát của nó chỉ ra rằng nó đã bị SIGINT giết).

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

Trên, bash, shvà sleepnhận SIGINT khi tôi nhấn Ctrl-C, nhưng shlối ra bình thường với một mã số 0 xuất cảnh, nên bashbỏ qua SIGINT, đó là lý do chúng ta thấy "ở đây".

ping, ít nhất là một từ iputils, hành xử như vậy. Khi bị gián đoạn, nó sẽ in các số liệu thống kê và thoát với trạng thái thoát 0 hoặc 1 tùy thuộc vào việc ping của nó có được trả lời hay không. Vì vậy, khi bạn nhấn Ctrl-C trong khi pingđang chạy, bashlưu ý rằng bạn đã nhấn Ctrl-Ctrong trình xử lý SIGINT của nó, nhưng vì pingthoát bình thường, bashkhông thoát.

Nếu bạn thêm một sleep 1vòng lặp đó và nhấn Ctrl-Ctrong khi sleepđang chạy, vì sleepkhông có trình xử lý đặc biệt nào trên SIGINT, nó sẽ chết và báo cáo bashrằng nó đã chết vì SIGINT, và trong trường hợp đó bashsẽ thoát ra (nó thực sự sẽ tự chết bằng SIGINT để báo cáo sự gián đoạn cho cha mẹ của nó).

Về lý do tại sao bashhành xử như vậy, tôi không chắc chắn và tôi lưu ý rằng hành vi không phải lúc nào cũng mang tính quyết định. Tôi vừa hỏi câu hỏi trong bashdanh sách gửi thư phát triển ( Cập nhật : @Jilles hiện đã đóng đinh lý do trong câu trả lời của anh ấy ).

Vỏ khác duy nhất tôi thấy có hành vi tương tự là ksh93 (Cập nhật, như được đề cập bởi @Jilles, FreeBSD cũng vậysh ). Ở đó, SIGINT dường như bị bỏ qua rõ ràng. Và ksh93thoát ra bất cứ khi nào một lệnh bị giết bởi SIGINT.

Bạn có hành vi tương tự như bashtrên nhưng cũng:

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

Không xuất "kiểm tra". Đó là, nó thoát ra (bằng cách tự giết bằng SIGINT ở đó) nếu lệnh mà nó đang chờ chết của SIGINT, ngay cả khi nó, chính nó đã không nhận được SIGINT đó.

Một công việc xung quanh sẽ là thêm một:

trap 'exit 130' INT

Ở đầu tập lệnh buộc bashphải thoát khi nhận được SIGINT (lưu ý rằng trong mọi trường hợp, SIGINT sẽ không được xử lý đồng bộ, chỉ sau khi lệnh hiện đang chạy).

Lý tưởng nhất là chúng tôi muốn báo cáo với cha mẹ rằng chúng tôi đã chết vì SIGINT (để nếu đó là một bashtập lệnh khác chẳng hạn, bashtập lệnh đó cũng bị gián đoạn). Làm một cái exit 130không giống như chết của SIGINT (mặc dù một số shell sẽ được đặt $?thành cùng một giá trị cho cả hai trường hợp), tuy nhiên, nó thường được sử dụng để báo cáo cái chết của SIGINT (trên các hệ thống có SIGINT là 2).

Tuy nhiên bash, ksh93hoặc FreeBSD sh, không hoạt động. Tình trạng thoát 130 đó không được coi là một cái chết bởi SIGINT và tập lệnh gốc sẽ không hủy bỏ ở đó.

Vì vậy, một giải pháp thay thế tốt hơn có thể là giết chính chúng ta bằng SIGINT khi nhận được SIGINT:

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

Giải thích là bash thực hiện WCE (chờ đợi và thoát hợp tác) cho SIGINT và SIGQUIT mỗi http://www.cons.org/cracauer/sigint.html . Điều đó có nghĩa là nếu bash nhận SIGINT hoặc SIGQUIT trong khi chờ quá trình thoát, nó sẽ đợi cho đến khi quá trình thoát và sẽ tự thoát nếu quá trình thoát khỏi tín hiệu đó. Điều này đảm bảo rằng các chương trình sử dụng SIGINT hoặc SIGQUIT trong giao diện người dùng của họ sẽ hoạt động như mong đợi (nếu tín hiệu không khiến chương trình kết thúc, tập lệnh sẽ tiếp tục bình thường).

Một nhược điểm xuất hiện với các chương trình bắt SIGINT hoặc SIGQUIT nhưng sau đó chấm dứt vì nó nhưng sử dụng lối thoát bình thường () thay vì gửi lại tín hiệu cho chính chúng. Có thể không thể làm gián đoạn các tập lệnh gọi các chương trình như vậy. Tôi nghĩ rằng sửa chữa thực sự có trong các chương trình như ping và ping6.

Hành vi tương tự được thực hiện bởi ksh93 và FreeBSD's / bin / sh, nhưng không phải bởi hầu hết các shell khác.

Khi bạn phỏng đoán, điều này là do SIGINT được gửi đến quy trình cấp dưới và lớp vỏ tiếp tục sau khi quá trình đó thoát ra.

Để xử lý việc này theo cách tốt hơn, bạn có thể kiểm tra trạng thái thoát của các lệnh đang chạy. Mã trả về Unix mã hóa cả phương thức mà một quá trình đã thoát (cuộc gọi hệ thống hoặc tín hiệu) và giá trị nào được truyền đến exit()hoặc tín hiệu nào kết thúc quá trình. Điều này khá phức tạp, nhưng cách sử dụng nhanh nhất là để biết rằng một quá trình bị chấm dứt bởi tín hiệu sẽ có mã trả về khác không. Do đó, nếu bạn kiểm tra mã trả về trong tập lệnh của mình, bạn có thể tự thoát nếu quá trình con bị chấm dứt, loại bỏ sự cần thiết của các lệnh không liên quan như sleepcác cuộc gọi không cần thiết . Một cách nhanh chóng để thực hiện điều này trong toàn bộ tập lệnh của bạn là sử dụng set -e, mặc dù nó có thể yêu cầu một vài điều chỉnh cho các lệnh có trạng thái thoát là một giá trị khác.

Thiết bị đầu cuối thông báo control-c và gửi INTtín hiệu đến nhóm quy trình nền trước, ở đây bao gồm cả vỏ, vì pingchưa tạo ra một nhóm quy trình tiền cảnh mới. Điều này là dễ dàng để xác minh bằng cách bẫy INT.

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

Nếu lệnh đang chạy đã tạo ra một nhóm quy trình tiền cảnh mới, thì control-c sẽ chuyển đến nhóm quy trình đó chứ không phải vào trình bao. Trong trường hợp đó, shell sẽ cần kiểm tra mã thoát, vì nó sẽ không được báo hiệu bởi thiết bị đầu cuối.

( INTbằng cách này, việc xử lý trong các shell có thể rất phức tạp, vì shell đôi khi cần bỏ qua tín hiệu, và đôi khi không. Nguồn lặn nếu tò mò hoặc suy ngẫm tail -f /etc/passwd; echo foo:)

Chà, tôi đã cố gắng thêm một sleep 1tập lệnh bash, và bang!
Bây giờ tôi có thể ngăn chặn nó với hai Ctrl+C.

Khi nhấn Ctrl+C, SIGINTtín hiệu được gửi đến quá trình hiện đang được thực thi, lệnh nào được chạy bên trong vòng lặp. Sau đó, quá trình subshell tiếp tục thực hiện lệnh tiếp theo trong vòng lặp, bắt đầu một quá trình khác. Để có thể dừng tập lệnh, cần phải gửi hai SIGINTtín hiệu, một để làm gián đoạn lệnh hiện tại trong thực thi và một để làm gián đoạn quá trình subshell .

Trong tập lệnh mà không có sleepcuộc gọi, nhấn Ctrl+Cthực sự nhanh và nhiều lần dường như không hoạt động và không thể thoát khỏi vòng lặp. Tôi đoán là nhấn hai lần là không đủ nhanh để làm cho nó chỉ trong một thời điểm thích hợp giữa sự gián đoạn của quá trình thực hiện hiện tại và bắt đầu quá trình tiếp theo. Mỗi lần Ctrl+Cnhấn sẽ gửi một SIGINTđến một quá trình được thực hiện bên trong vòng lặp, nhưng không gửi đến lớp con .

Trong kịch bản với sleep 1, cuộc gọi này sẽ tạm dừng thực thi trong một giây và khi bị gián đoạn bởi lần đầu tiên Ctrl+C(lần đầu tiên SIGINT), lớp con sẽ mất nhiều thời gian hơn để thực hiện lệnh tiếp theo. Vì vậy, bây giờ, thứ hai Ctrl+C(thứ hai SIGINT) sẽ đi đến lớp con và việc thực thi tập lệnh sẽ kết thúc.

Thử đi:

#!/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

Bây giờ thay đổi dòng đầu tiên thành:

#!/bin/sh

và thử lại - xem liệu ping có bị gián đoạn không.

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

ví dụ pgrep -f firefoxsẽ grep bộ vi xử lý đang chạy firefoxvà sẽ lưu bộ PID này vào một tệp có tên any_file_name. Lệnh 'sed' sẽ thêm killvào đầu số PID trong tệp 'any_file_name'. Dòng thứ ba sẽ any_file_nametập tin thực thi. Bây giờ dòng tiếp theo sẽ giết chết PID có sẵn trong tệp any_file_name. Viết bốn dòng trên vào một tệp và thực thi tệp đó có thể thực hiện Control- C. Làm việc hoàn toàn tốt cho tôi.

Nếu bất kỳ ai quan tâm đến việc sửa lỗi cho bashtính năng này và không quá quan tâm đến triết lý đằng sau nó , thì đây là một đề xuất:

Đừng chạy trực tiếp lệnh có vấn đề, nhưng từ một trình bao bọc mà a) chờ nó kết thúc b) không gây rối với tín hiệu và c) không tự thực hiện cơ chế WCE, mà chỉ chết khi nhận được a SIGINT.

Một trình bao bọc như vậy có thể được thực hiện với awk+ system()chức năng của nó .

$ 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

Đặt một tập lệnh như của OP:

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

Bạn là nạn nhân của một lỗi bash nổi tiếng. Bash không kiểm soát công việc cho các kịch bản đó là một sai lầm.

Điều xảy ra là bash chạy các chương trình bên ngoài trong một nhóm quy trình khác với việc sử dụng cho chính tập lệnh. Vì nhóm quy trình TTY được đặt thành nhóm quy trình của quy trình tiền cảnh hiện tại, chỉ có quy trình tiền cảnh này bị hủy và vòng lặp trong tập lệnh shell tiếp tục.

Để xác minh: Tìm nạp và biên dịch Shell Bourne gần đây thực hiện pgrp (1) dưới dạng chương trình dựng sẵn, sau đó thêm / bin / ngủ 100 (hoặc / usr / bin / ngủ tùy thuộc vào nền tảng của bạn) vào vòng lặp tập lệnh Vỏ Bourne. Sau khi bạn sử dụng ps (1) để lấy ID tiến trình cho lệnh ngủ và bash chạy tập lệnh, hãy gọi pgrp <pid>và thay thế "<pid>" bằng ID tiến trình của chế độ ngủ và bash chạy tập lệnh. Bạn sẽ thấy ID nhóm quy trình khác nhau. Bây giờ gọi một cái gì đó như pgrp < /dev/pts/7(thay thế tên tty bằng tty được sử dụng bởi tập lệnh) để có được nhóm quy trình tty hiện tại. Nhóm quy trình TTY bằng với nhóm quy trình của lệnh ngủ.

Để khắc phục: sử dụng một vỏ khác.

Các nguồn Bourne Shell gần đây nằm trong gói công cụ schily của tôi mà bạn có thể tìm thấy ở đây:

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