Як запобігти SIGPIPE (або правильно поводитися з ними)

У мене невелика серверна програма, яка приймає з'єднання в TCP або локальному сокеті UNIX, читає просту команду і, залежно від команди, надсилає відповідь. Проблема полягає в тому, що клієнт може не мати інтересу до відповіді іноді і виходить зранку, тому запис у цей сокет спричинить SIGPIPE і призведе до збою мого сервера. Яка найкраща практика для запобігання аварій тут? Чи є спосіб перевірити, чи читається інша сторона рядка? (select (), здається, не працює тут, оскільки завжди говорить, що сокет можна записати). Або я повинен просто зловити SIGPIPE за допомогою обробника і проігнорувати його?

Як правило, ви хочете ігнорувати SIGPIPEта керувати помилкою безпосередньо у своєму коді. Це тому, що обробники сигналів в C мають багато обмежень щодо того, що вони можуть робити.

Найбільш портативний спосіб зробити це - встановити SIGPIPEобробник SIG_IGN. Це запобіжить появі SIGPIPEсигналу будь-якої розетки або труби .

Щоб ігнорувати SIGPIPEсигнал, використовуйте наступний код:

signal(SIGPIPE, SIG_IGN);

Якщо ви використовуєте send()дзвінок, ще одним варіантом є використання MSG_NOSIGNALопції, яка SIGPIPEвимикає поведінку на основі виклику. Зауважте, що не всі операційні системи підтримують MSG_NOSIGNALпрапор.

Нарешті, ви також можете розглянути SO_SIGNOPIPEпрапор сокета, який можна встановити setsockopt()в деяких операційних системах. Це не призведе SIGPIPEдо того, що він буде записаний просто у розетки, на які він встановлений.

Інший метод полягає в зміні сокета, щоб він ніколи не створював SIGPIPE на write (). Це зручніше в бібліотеках, де, можливо, не потрібно глобального обробника сигналу для SIGPIPE.

У більшості систем на базі BSD (MacOS, FreeBSD ...) (якщо ви користуєтесь C / C ++), ви можете це зробити за допомогою:

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

При цьому фактично замість генерування сигналу SIGPIPE повернеться EPIPE.

Я дуже спізнився на вечірку, але SO_NOSIGPIPEне є портативним і може не працювати у вашій системі (здається, це BSD).

Хорошою альтернативою, якщо ви працюєте, скажімо, у системі Linux без SO_NOSIGPIPEвстановлення MSG_NOSIGNALпрапора на ваш виклик send (2).

Приклад заміни write(...)на send(...,MSG_NOSIGNAL)(див. Коментар nobar )

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

У цій публікації я описав можливе рішення для випадку Solaris, коли немає ні SO_NOSIGPIPE, ні MSG_NOSIGNAL.

Натомість нам доведеться тимчасово придушити SIGPIPE у поточному потоці, який виконує код бібліотеки. Ось як це зробити: щоб придушити SIGPIPE, ми спочатку перевіряємо, чи він очікує на розгляд. Якщо це так, це означає, що він заблокований у цій темі, і ми нічого не повинні робити. Якщо бібліотека генерує додатковий SIGPIPE, вона буде об'єднана з відкладеною, і це неоперативний варіант. Якщо SIGPIPE не очікується, ми блокуємо його в цій нитці, а також перевіряємо, чи він уже заблокований. Тоді ми вільні виконувати свої записи. Коли ми маємо відновити SIGPIPE до його початкового стану, ми робимо наступне: якщо SIGPIPE спочатку очікував на розгляд, ми нічого не робимо. Інакше ми перевіряємо, чи зараз це очікує на розгляд. Якщо це так (а це означає, що з дій, що генерували один або декілька SIGPIPE), ми чекаємо його в цій темі, таким чином очищаючи його очікуваний статус (для цього ми використовуємо sigtimedwait () з нульовим тайм-аутом; це уникнути блокування в сценарії, коли зловмисний користувач відправляє SIGPIPE вручну на весь процес: у цьому випадку ми побачимо його в очікуванні, але інша нитка може впорайтеся з цим, перш ніж ми змінили, щоб його почекати). Після очищення статусу очікування ми розблокуємо SIGPIPE в цій темі, але тільки якщо вона не була заблокована спочатку.

Приклад коду за адресою https://github.com/kroki/XProbes/blob/1447f3d93b6dbf273919af15e59f35cca58fcc23/src/libxprobes.c#L156

Обробляйте SIGPIPE локально

Зазвичай найкраще обробляти помилку локально, а не глобальним обробником сигнальних подій, оскільки на місцевому рівні у вас буде більше контексту щодо того, що відбувається і який спосіб звернутися.

У мене в одному з моїх програм є комунікаційний рівень, який дозволяє моїй програмі спілкуватися із зовнішнім аксесуаром. Коли виникає помилка запису, я кидаю і виняток у комунікаційному шарі і даю йому міхур до блоку спробувати вловлювати, щоб обробити його там.

Код:

Код для ігнорування сигналу SIGPIPE, щоб ви могли обробляти його локально:

// 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);

Цей код запобігає підвищенню сигналу SIGPIPE, але ви отримаєте помилку читання / запису при спробі використання сокета, тому вам потрібно буде перевірити це.

Ви не можете запобігти виходу процесу на дальньому кінці труби, і якщо він закінчується до того, як ви закінчите запис, ви отримаєте сигнал SIGPIPE. Якщо ви будете сигналізувати SIG_IGN, то ваше повідомлення повернеться з помилкою - і вам потрібно зазначити та реагувати на цю помилку. Просто ловити та ігнорувати сигнал у обробнику - це не дуже гарна ідея - ви повинні зауважити, що труба зараз не виходить з ладу та модифікує поведінку програми, щоб вона не записувалась у трубу знову (тому що сигнал знову буде генеруватися та ігноруватися знову, і ви спробуєте ще раз, і весь процес може тривати довгий час і витрачати багато процесорної потужності).

Або я повинен просто зловити SIGPIPE за допомогою обробника і проігнорувати його?

Я вважаю, що це правильно. Ви хочете знати, коли інший кінець закрив їх дескриптор, і це те, що говорить SIGPIPE.

Сем

Посібник Linux сказав:

EPIPE Місцевий кінець вимкнено на розетці, орієнтованій на з'єднання. У цьому випадку процес також отримає SIGPIPE, якщо не встановлено MSG_NOSIGNAL.

Але для Ubuntu 12.04 це не так. Я написав тест на цей випадок, і я завжди отримую EPIPE від SIGPIPE. SIGPIPE створюється, якщо я спробую записати в той самий розбитий сокет другий раз. Тому вам не потрібно ігнорувати SIGPIPE, якщо цей сигнал трапляється, це означає логічну помилку у вашій програмі.

Яка найкраща практика для запобігання аварій тут?

Або відключіть вивіски, як усі, або вловлюйте та ігноруйте помилку.

Чи є спосіб перевірити, чи читається інша сторона рядка?

Так, використовуйте select ().

select (), здається, не працює тут, оскільки це завжди говорить, що сокет можна записати.

Вам потрібно вибрати біти для читання . Ви , ймовірно , можете ігнорувати записи біт.

Коли дальній кінець закриє свою обробку файлів, функція Select скаже вам, що є дані, готові прочитати. Перейшовши і прочитавши це, ви отримаєте 0 байтів, і ось як ОС повідомляє вам, що обробка файлу закрита.

Єдиний раз, коли ви не можете ігнорувати біти запису, це якщо ви надсилаєте великі обсяги, і є ризик того, що інший кінець буде відкладений, що може призвести до заповнення ваших буферів. Якщо це трапиться, то спроба запису в ручку файлу може призвести до блокування вашої програми / потоку або відмови. Вибір тестування перед написанням захистить вас від цього, але це не гарантує, що інший кінець є здоровим або що ваші дані надійдуть.

Зауважте, що ви можете отримати підписи з наближення (), а також під час написання.

Закривання видаляє будь-які завантажені дані. Якщо інший кінець уже закритий, закрити не вдасться, і ви отримаєте вивіску.

Якщо ви використовуєте захищений TCPIP, то успішне записування означає, що ваші дані надійдуть у чергу для надсилання, це не означає, що вони надіслані. Поки ви успішно не зателефонували, ви не знаєте, що ваші дані надіслані.

Sigpipe повідомляє вам, що щось пішло не так, не говорить вам, що і що ви з цим робити.

У сучасній системі POSIX (тобто Linux) ви можете використовувати sigprocmask()функцію.

#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 ...
}

Якщо ви хочете відновити попередній стан пізніше, не забудьте зберегти old_stateдесь безпечне місце. Якщо ви викликаєте цю функцію кілька разів, вам потрібно використовувати стек або зберегти лише перший або останній old_state... або, можливо, мати функцію, яка видаляє певний заблокований сигнал.

Для отримання додаткової інформації читайте сторінку man .