¿La tubería rota ya no finaliza los programas?

Question

Cuando canalizas dos procesos y matas el que está en la "salida" de la tubería, el primer proceso solía recibir la señal de "Tubería rota", que generalmente también lo terminaba.P.ej.correr

$> do_something_intensive | less

y luego saliendo menos se utiliza para devolverle inmediatamente a un shell responsivo, en un SuSE8 o versiones anteriores.Cuando lo intento hoy, hacer_algo_intensivo Obviamente todavía se está ejecutando hasta que lo elimine manualmente.Parece que algo ha cambiado (¿simplista?shell?) que hace que el programa ignore las "tuberías rotas"...

¿Alguien de ustedes tiene pistas sobre esto?¿Cómo restaurar el comportamiento anterior?¿Por qué se ha cambiado (o por qué siempre existieron múltiples semánticas)?

editar :pruebas adicionales (usando strace) revelan que "SIGPIPE" es generado, pero que el programa no se interrumpa.Un simple

#include <stdio.h>
int main() 
{
   while(1) printf("dumb test\n");
   exit(0);
}

Seguirá con un sinfín

--- SIGPIPE (Broken pipe) @ 0 (0) ---
write(1, "dumb test\ndumb test\ndumb test\ndu"..., 1024) = -1 EPIPE (Broken pipe)

cuando menos es asesinado.Seguramente podría programar un controlador de señales en mi programa y asegurarme de que termine, pero estoy más buscando alguna variable de entorno o una opción de shell que obligue a los programas a terminar en SIGPIPE.

editar de nuevo:parece ser un problema específico de tcsh (bash lo maneja correctamente) y dependiente del terminal (Eterm 0.9.4)

Answer 1

Gracias por tus consejos, la solución está cada vez más cerca...

Según la página de manual de tcsh, "los shells sin inicio de sesión heredan el comportamiento de terminación de sus padres.Otras señales tienen los valores que el caparazón heredó de su padre."

Lo que sugiere mi Terminal en realidad es la raíz del problema...si ignoró SIGPIPE, el shell mismo ignorará SIGPIPE también...

editar: Tengo la confirmación definitiva de que el problema solo surge con Eterm+tcsh y encontré una señal sospechosamente faltante (SIGPIPE,SIG_DFL) en el código fuente de Eterm.Creo que eso cierra el caso.

Answer 2

Bueno, si se intenta escribir en una tubería después de que el lector se ha ido, se genera una señal SIGPIPE.La aplicación tiene la capacidad de captar esta señal, pero si no lo hace, el proceso finaliza.

El SIGPIPE no se generará hasta que el proceso de llamada intente escribir, por lo que si no hay más resultados, no se generará.

Answer 3

¿Ha cambiado en algo "hacer algo intensivo"?

Como Daniel ha mencionado, SIGPIPE no es una señal mágica de "tu tubería se fue", sino más bien una señal de "buen intento, ya no puedes leer/escribir esa tubería".

Si tiene el control de "hacer algo intensivo", puede cambiarlo para escribir algún resultado de "indicador de progreso" a medida que gira.Esto levantaría el SIGPIPE oportunamente.