Cách ngăn chặn SIGPIPE (hoặc xử lý chúng đúng cách)

Tôi có một chương trình máy chủ nhỏ chấp nhận các kết nối trên ổ cắm TCP hoặc UNIX cục bộ, đọc một lệnh đơn giản và tùy theo lệnh sẽ gửi trả lời. Vấn đề là đôi khi khách hàng không có hứng thú với câu trả lời và thoát ra sớm, do đó, việc ghi vào ổ cắm đó sẽ gây ra SIGPIPE và khiến máy chủ của tôi gặp sự cố. Cách tốt nhất để ngăn chặn sự cố ở đây là gì? Có cách nào để kiểm tra xem phía bên kia của dòng vẫn đang đọc không? (select () dường như không hoạt động ở đây vì nó luôn nói rằng ổ cắm có thể ghi được). Hay tôi chỉ nên bắt SIGPIPE bằng một trình xử lý và bỏ qua nó?

Bạn thường muốn bỏ qua SIGPIPEvà xử lý lỗi trực tiếp trong mã của bạn. Điều này là do bộ xử lý tín hiệu trong C có nhiều hạn chế về những gì họ có thể làm.

Cách di động nhất để làm điều này là đặt SIGPIPEtrình xử lý SIG_IGN. Điều này sẽ ngăn chặn bất kỳ ổ cắm hoặc đường ống ghi gây ra SIGPIPEtín hiệu.

Để bỏ qua SIGPIPEtín hiệu, sử dụng mã sau đây:

signal(SIGPIPE, SIG_IGN);

Nếu bạn đang sử dụng send()cuộc gọi, một tùy chọn khác là sử dụng MSG_NOSIGNALtùy chọn, điều này sẽ SIGPIPEtắt hành vi trên cơ sở mỗi cuộc gọi. Lưu ý rằng không phải tất cả các hệ điều hành đều hỗ trợ MSG_NOSIGNALcờ.

Cuối cùng, bạn cũng có thể muốn xem xét SO_SIGNOPIPEcờ ổ cắm có thể được đặt setsockopt()trên một số hệ điều hành. Điều này sẽ ngăn không SIGPIPEbị gây ra bởi chỉ ghi vào ổ cắm được đặt.

Một phương pháp khác là thay đổi ổ cắm để nó không bao giờ tạo SIGPIPE trên write (). Điều này thuận tiện hơn trong các thư viện, nơi bạn có thể không muốn xử lý tín hiệu toàn cầu cho SIGPIPE.

Trên hầu hết các hệ thống dựa trên BSD (MacOS, FreeBSD ...), (giả sử bạn đang sử dụng C / C ++), bạn có thể thực hiện việc này với:

int set = 1;
setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));

Với hiệu ứng này, thay vì tín hiệu SIGPIPE được tạo, EPIPE sẽ được trả về.

Tôi đến bữa tiệc rất muộn, nhưng SO_NOSIGPIPEkhông di động và có thể không hoạt động trên hệ thống của bạn (có vẻ như đó là một điều BSD).

Một giải pháp thay thế tuyệt vời nếu bạn sử dụng hệ thống Linux mà không cần SO_NOSIGPIPEđặt MSG_NOSIGNALcờ cho cuộc gọi gửi (2) của bạn.

Ví dụ thay thế write(...)bằng send(...,MSG_NOSIGNAL)(xem bình luận của quý tộc )

char buf[888];
//write( sockfd, buf, sizeof(buf) );
send(    sockfd, buf, sizeof(buf), MSG_NOSIGNAL );

Trong bài viết này, tôi đã mô tả giải pháp khả thi cho trường hợp Solaris khi cả SO_NOSIGPIPE và MSG_NOSIGNAL đều không khả dụng.

Thay vào đó, chúng ta phải tạm thời loại bỏ SIGPIPE trong luồng hiện tại thực thi mã thư viện. Dưới đây là cách thực hiện việc này: để chặn SIGPIPE, trước tiên chúng tôi kiểm tra xem nó có đang chờ xử lý không. Nếu có, điều này có nghĩa là nó bị chặn trong chuỗi này và chúng ta không phải làm gì. Nếu thư viện tạo SIGPIPE bổ sung, nó sẽ được hợp nhất với thư đang chờ xử lý và đó là điều không có. Nếu SIGPIPE không chờ xử lý thì chúng tôi sẽ chặn nó trong chuỗi này và kiểm tra xem nó đã bị chặn chưa. Sau đó, chúng tôi được tự do thực hiện các bài viết của chúng tôi. Khi chúng tôi khôi phục SIGPIPE về trạng thái ban đầu, chúng tôi sẽ làm như sau: nếu SIGPIPE đang chờ xử lý ban đầu, chúng tôi không làm gì cả. Nếu không, chúng tôi kiểm tra nếu nó đang chờ xử lý. Nếu có (nghĩa là các hành động bên ngoài đã tạo ra một hoặc nhiều SIGPIPE), thì chúng ta sẽ đợi nó trong chuỗi này, do đó xóa trạng thái chờ xử lý của nó (để thực hiện điều này, chúng tôi sử dụng sigtimedwait () với thời gian chờ bằng 0; điều này là để tránh chặn trong một kịch bản mà người dùng độc hại đã gửi SIGPIPE theo cách thủ công cho toàn bộ quá trình: trong trường hợp này chúng tôi sẽ thấy nó đang chờ xử lý, nhưng luồng khác có thể xử lý nó trước khi chúng tôi có một sự thay đổi để chờ đợi nó). Sau khi xóa trạng thái chờ xử lý, chúng tôi bỏ chặn SIGPIPE trong chuỗi này, nhưng chỉ khi nó không bị chặn ban đầu.

Mã ví dụ tại https://github.com/kroki/XPcoat/blob/1447f3d93b6dbf273919af15e59f35cca58fcc23/src/libxprobes.c#L156

Xử lý SIGPIPE tại địa phương

Thông thường tốt nhất là xử lý lỗi cục bộ thay vì xử lý sự kiện tín hiệu toàn cầu vì tại địa phương, bạn sẽ có nhiều bối cảnh hơn về những gì đang diễn ra và những gì cần phải xử lý.

Tôi có một lớp giao tiếp trong một trong những ứng dụng của mình cho phép ứng dụng của tôi giao tiếp với một phụ kiện bên ngoài. Khi xảy ra lỗi ghi, tôi ném và ngoại lệ trong lớp giao tiếp và để nó nổi lên thành một khối thử bắt để xử lý nó ở đó.

Mã số:

Mã để bỏ qua tín hiệu SIGPIPE để bạn có thể xử lý nó cục bộ là:

// We expect write failures to occur but we want to handle them where 
// the error occurs rather than in a SIGPIPE handler.
signal(SIGPIPE, SIG_IGN);

Mã này sẽ ngăn tín hiệu SIGPIPE được tăng lên, nhưng bạn sẽ gặp lỗi đọc / ghi khi cố gắng sử dụng ổ cắm, vì vậy bạn sẽ cần kiểm tra xem.

Bạn không thể ngăn quá trình ở đầu xa của một đường ống thoát ra và nếu nó thoát ra trước khi bạn viết xong, bạn sẽ nhận được tín hiệu SIGPIPE. Nếu bạn SIG_IGN tín hiệu, thì ghi của bạn sẽ trở lại với một lỗi - và bạn cần lưu ý và phản ứng với lỗi đó. Chỉ bắt và bỏ qua tín hiệu trong trình xử lý không phải là ý hay - bạn phải lưu ý rằng đường ống hiện không còn tồn tại và sửa đổi hành vi của chương trình để nó không ghi lại vào đường ống (vì tín hiệu sẽ được tạo lại và bỏ qua một lần nữa, và bạn sẽ thử lại, và toàn bộ quá trình có thể diễn ra trong một thời gian dài và lãng phí rất nhiều năng lượng CPU).

Hay tôi chỉ nên bắt SIGPIPE bằng một trình xử lý và bỏ qua nó?

Tôi tin rằng điều đó là đúng. Bạn muốn biết khi nào đầu kia đã đóng mô tả của họ và đó là những gì SIGPIPE nói với bạn.

Sam

Hướng dẫn sử dụng Linux cho biết:

EPIPE Đầu cuối cục bộ đã bị tắt trên ổ cắm hướng kết nối. Trong trường hợp này, quy trình cũng sẽ nhận được SIGPIPE trừ khi MSG_NOSIGNAL được đặt.

Nhưng đối với Ubuntu 12.04 thì không đúng. Tôi đã viết một bài kiểm tra cho trường hợp đó và tôi luôn nhận được EPIPE mà không có SIGPIPE. SIGPIPE bị phát sinh nếu tôi cố gắng ghi vào cùng một ổ cắm bị hỏng lần thứ hai. Vì vậy, bạn không cần bỏ qua SIGPIPE nếu tín hiệu này xảy ra, điều đó có nghĩa là lỗi logic trong chương trình của bạn.

Cách tốt nhất để ngăn chặn sự cố ở đây là gì?

Hoặc vô hiệu hóa sigpipes theo mọi người, hoặc bắt và bỏ qua lỗi.

Có cách nào để kiểm tra xem phía bên kia của dòng vẫn đang đọc không?

Có, sử dụng select ().

select () dường như không hoạt động ở đây vì nó luôn nói rằng socket có thể ghi được.

Bạn cần chọn trên các bit đọc . Bạn có thể bỏ qua các bit ghi .

Khi đầu xa đóng xử lý tệp của nó, chọn sẽ cho bạn biết rằng có dữ liệu sẵn sàng để đọc. Khi bạn đọc và đọc nó, bạn sẽ nhận lại 0 byte, đó là cách HĐH cho bạn biết rằng phần xử lý tệp đã bị đóng.

Lần duy nhất bạn không thể bỏ qua các bit ghi là nếu bạn đang gửi khối lượng lớn và có nguy cơ đầu bên kia bị tồn đọng, điều này có thể khiến bộ đệm của bạn bị đầy. Nếu điều đó xảy ra, thì việc cố gắng ghi vào xử lý tệp có thể khiến chương trình / luồng của bạn bị chặn hoặc không thành công. Kiểm tra chọn trước khi viết sẽ bảo vệ bạn khỏi điều đó, nhưng không đảm bảo rằng đầu kia khỏe mạnh hoặc dữ liệu của bạn sẽ đến.

Lưu ý rằng bạn có thể nhận được một sigpipe từ close (), cũng như khi bạn viết.

Đóng tuôn ra bất kỳ dữ liệu đệm. Nếu đầu kia đã bị đóng, thì đóng sẽ thất bại và bạn sẽ nhận được một sigpipe.

Nếu bạn đang sử dụng TCPIP được đệm, thì việc ghi thành công chỉ có nghĩa là dữ liệu của bạn đã được xếp hàng để gửi, điều đó không có nghĩa là nó đã được gửi. Cho đến khi bạn gọi thành công, bạn không biết rằng dữ liệu của mình đã được gửi.

Sigpipe nói với bạn điều gì đó đã sai, nó không cho bạn biết điều gì hoặc bạn nên làm gì với nó.

Trong hệ thống POSIX hiện đại (tức là Linux), bạn có thể sử dụng sigprocmask()chức năng.

#include <signal.h>

void block_signal(int signal_to_block /* i.e. SIGPIPE */ )
{
    sigset_t set;
    sigset_t old_state;

    // get the current state
    //
    sigprocmask(SIG_BLOCK, NULL, &old_state);

    // add signal_to_block to that existing state
    //
    set = old_state;
    sigaddset(&set, signal_to_block);

    // block that signal also
    //
    sigprocmask(SIG_BLOCK, &set, NULL);

    // ... deal with old_state if required ...
}

Nếu bạn muốn khôi phục trạng thái trước đó sau đó, hãy đảm bảo lưu trạng thái old_statean toàn. Nếu bạn gọi hàm đó nhiều lần, bạn cần sử dụng ngăn xếp hoặc chỉ lưu lần đầu tiên hoặc lần cuối old_state... hoặc có thể có chức năng loại bỏ tín hiệu bị chặn cụ thể.

Để biết thêm thông tin đọc trang người đàn ông .