Cómo prevenir los SIGPIPE (o manejarlos adecuadamente)

Tengo un pequeño programa de servidor que acepta conexiones en un socket TCP o local de UNIX, lee un comando simple y, dependiendo del comando, envía una respuesta. El problema es que el cliente puede no tener interés en la respuesta a veces y sale temprano, por lo que escribir en ese socket provocará un SIGPIPE y hará que mi servidor se bloquee. ¿Cuál es la mejor práctica para evitar el accidente aquí? ¿Hay alguna manera de verificar si el otro lado de la línea todavía está leyendo? (select () no parece funcionar aquí, ya que siempre dice que el socket es grabable). ¿O debería atrapar el SIGPIPE con un controlador e ignorarlo?

En general, desea ignorar SIGPIPEy manejar el error directamente en su código. Esto se debe a que los manejadores de señales en C tienen muchas restricciones sobre lo que pueden hacer.

La forma más portátil de hacer esto es configurar el SIGPIPEcontrolador en SIG_IGN. Esto evitará que cualquier escritura de socket o tubería provoque una SIGPIPEseñal.

Para ignorar la SIGPIPEseñal, use el siguiente código:

signal(SIGPIPE, SIG_IGN);

Si está usando la send()llamada, otra opción es usar la MSG_NOSIGNALopción, que desactivará el SIGPIPEcomportamiento por llamada. Tenga en cuenta que no todos los sistemas operativos admiten la MSG_NOSIGNALbandera.

Por último, es posible que también desee considerar el SO_SIGNOPIPEindicador de socket que se puede configurar setsockopt()en algunos sistemas operativos. Esto evitará que SIGPIPEsea ​​causado por escrituras solo en los sockets en los que está configurado.

Otro método es cambiar el socket para que nunca genere SIGPIPE en write (). Esto es más conveniente en las bibliotecas, donde es posible que no desee un controlador de señal global para SIGPIPE.

En la mayoría de los sistemas basados ​​en BSD (MacOS, FreeBSD ...), (suponiendo que esté usando C / C ++), puede hacer esto con:

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

Con esto en efecto, en lugar de que se genere la señal SIGPIPE, se devolverá EPIPE.

Llego súper tarde a la fiesta, pero SO_NOSIGPIPEno es portátil y es posible que no funcione en su sistema (parece ser algo BSD).

Una buena alternativa si está en, digamos, un sistema Linux sin SO_NOSIGPIPEsería establecer el MSG_NOSIGNALindicador en su llamada send (2).

Ejemplo reemplazado write(...)por send(...,MSG_NOSIGNAL)(ver el comentario de nobar )

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

En esto publicación describí una posible solución para el caso de Solaris cuando ni SO_NOSIGPIPE ni MSG_NOSIGNAL están disponibles.

En cambio, tenemos que suprimir temporalmente SIGPIPE en el hilo actual que ejecuta el código de la biblioteca. Aquí se explica cómo hacerlo: para suprimir SIGPIPE, primero verificamos si está pendiente. Si lo hace, esto significa que está bloqueado en este hilo, y no tenemos que hacer nada. Si la biblioteca genera SIGPIPE adicional, se fusionará con la pendiente, y eso es un no-op. Si SIGPIPE no está pendiente, lo bloqueamos en este hilo y también verificamos si ya estaba bloqueado. Entonces somos libres de ejecutar nuestras escrituras. Cuando debemos restaurar SIGPIPE a su estado original, hacemos lo siguiente: si SIGPIPE estaba pendiente originalmente, no hacemos nada. De lo contrario, verificamos si está pendiente ahora. Si lo hace (lo que significa que nuestras acciones han generado uno o más SIGPIPE), lo esperamos en este hilo, limpiando así su estado pendiente (para hacer esto usamos sigtimedwait () con tiempo de espera cero; esto es para evitar el bloqueo en un escenario donde el usuario malintencionado envió SIGPIPE manualmente a un proceso completo: en este caso lo veremos pendiente, pero otro hilo puede manejarlo antes de que tengamos un cambio para esperarlo). Después de borrar el estado pendiente, desbloqueamos SIGPIPE en este hilo, pero solo si no se bloqueó originalmente.

Código de ejemplo en https://github.com/kroki/XProbes/blob/1447f3d93b6dbf273919af15e59f35cca58fcc23/src/libxprobes.c#L156

Manejar SIGPIPE localmente

Por lo general, es mejor manejar el error localmente en lugar de en un controlador de eventos de señal global, ya que localmente tendrá más contexto sobre lo que está sucediendo y qué recurso tomar.

Tengo una capa de comunicación en una de mis aplicaciones que permite que mi aplicación se comunique con un accesorio externo. Cuando se produce un error de escritura, lanzo una excepción en la capa de comunicación y dejo que se forme un bloque de prueba para manejarlo allí.

Código:

El código para ignorar una señal SIGPIPE para que pueda manejarlo localmente es:

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

Este código evitará que se active la señal SIGPIPE, pero recibirá un error de lectura / escritura cuando intente usar el socket, por lo que deberá verificarlo.

No puede evitar que el proceso en el otro extremo de una tubería salga, y si sale antes de que termine de escribir, obtendrá una señal SIGPIPE. Si SIG_IGN la señal, entonces su escritura volverá con un error, y debe anotar y reaccionar ante ese error. Simplemente atrapar e ignorar la señal en un controlador no es una buena idea: debe tener en cuenta que la tubería ahora está desactivada y modificar el comportamiento del programa para que no vuelva a escribir en la tubería (porque la señal se generará nuevamente y se ignorará nuevamente, y lo intentará nuevamente, y todo el proceso podría continuar durante mucho tiempo y desperdiciar mucha energía de la CPU).

¿O debería atrapar el SIGPIPE con un controlador e ignorarlo?

Creo que eso es correcto. Desea saber cuándo el otro extremo ha cerrado su descriptor y eso es lo que SIGPIPE le dice.

Sam

El manual de Linux dijo:

EPIPE El extremo local se ha apagado en un zócalo orientado a la conexión. En este caso, el proceso también recibirá un SIGPIPE a menos que se establezca MSG_NOSIGNAL.

Pero para Ubuntu 12.04 no está bien. Escribí una prueba para ese caso y siempre recibo EPIPE sin SIGPIPE. SIGPIPE se genera si intento escribir en el mismo socket roto por segunda vez. Por lo tanto, no necesita ignorar SIGPIPE si se produce esta señal, significa un error lógico en su programa.

¿Cuál es la mejor práctica para evitar el accidente aquí?

O deshabilite los sigpipes según todos, o atrape e ignore el error.

¿Hay alguna manera de verificar si el otro lado de la línea todavía está leyendo?

Sí, use select ().

select () no parece funcionar aquí, ya que siempre dice que el socket es grabable.

Debe seleccionar en los bits de lectura . Probablemente pueda ignorar los bits de escritura .

Cuando el extremo lejano cierra su identificador de archivo, select le indicará que hay datos listos para leer. Cuando vaya y lea eso, obtendrá 0 bytes, que es cómo el sistema operativo le dice que el identificador de archivo se ha cerrado.

El único momento en que no puede ignorar los bits de escritura es si está enviando grandes volúmenes, y existe el riesgo de que el otro extremo se acumule, lo que puede hacer que se llenen sus memorias intermedias. Si eso sucede, intentar escribir en el identificador del archivo puede hacer que su programa / hilo se bloquee o falle. Probar select antes de escribir lo protegerá de eso, pero no garantiza que el otro extremo esté sano o que sus datos lleguen.

Tenga en cuenta que puede obtener un sigpipe de close (), así como cuando escribe.

Cerrar elimina todos los datos almacenados en el búfer. Si el otro extremo ya se ha cerrado, entonces cerrará fallará y recibirá un letrero.

Si está utilizando TCPIP almacenado, entonces una escritura exitosa solo significa que sus datos se han puesto en cola para enviar, no significa que se hayan enviado. Hasta que cierre correctamente, no sabe que sus datos han sido enviados.

Sigpipe te dice que algo salió mal, no te dice qué o qué debes hacer al respecto.

En un sistema POSIX moderno (es decir, Linux), puede usar la sigprocmask()función.

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

Si desea restaurar el estado anterior más tarde, asegúrese de guardar el old_statelugar seguro. Si llama a esa función varias veces, debe usar una pila o guardar solo la primera o la últimaold_state ... o tal vez tener una función que elimine una señal bloqueada específica.

Para más información lea la página del manual .