1 votes

Lorsque vous envoyez l'entrée d'un programme vers un autre, que se passe-t-il pour le programme d'origine si le programme recevant la sortie est arrêté ?

Je transmets la sortie d'un programme de cette manière en utilisant bash :

programme1 | programme2

Si le programme2 est tué d'une manière ou d'une autre (dans mon cas par une erreur fatale PHP), que se passe-t-il avec l'instance de programme1 ?

3voto

Redbaron Points 523

Il dépend grandement de ce qu'est program1. Le logiciel doit être capable de gérer (ou d'ignorer) un signal SIGPIPE. program1 sera responsable de la gestion de l'erreur - si le logiciel est open source, vous devriez pouvoir déterminer ce qui se passe ou s'il intercepte/détecte un signal SIGPIPE. Si le logiciel ne fait rien de spécial avec les flux, il terminera probablement son exécution avant de transmettre les résultats. J'ai essayé un petit exemple pour illustrer le point en utilisant deux scripts php.

program1

#!/usr/bin/env php

``

program2

#!/usr/bin/env php
 $input )
{
    if( $key == $stop )
    {
        file_put_contents('program2.out', 'Mort!', FILE_APPEND);
        die(1);
    }

    file_put_contents('program2.out', $input, FILE_APPEND);
}

Lorsque vous exécutez ./program1 | ./program2, vous obtiendrez deux fichiers .out, un pour chaque programme. Dans l'exemple que j'ai exécuté, j'ai obtenu les fichiers suivants :

0
1
2
3
4
5
6
7
8
9
Fin

Et pour program2.out

0
1
2
3
4
Mort!

Le premier programme s'exécute et transmet son contenu au second. Vous remarquerez que le fichier .out du premier programme contient un ensemble complet de nombres et que le deuxième ne contient qu'un ensemble car il a été arrêté.

``

1voto

Egil Points 13196

Le tuyau sera cassé et le programme écrivant dans le tuyau recevra un signal SIGPIPE.

De GLIBC:

SIGPIPE Tuyau cassé. Si vous utilisez des tuyaux ou des FIFO, vous devez concevoir votre application de telle sorte qu'un processus ouvre le tuyau en lecture avant qu'un autre commence à écrire. Si le processus de lecture ne démarre jamais, ou se termine de manière inattendue, écrire dans le tuyau ou FIFO déclenche un signal SIGPIPE. Si SIGPIPE est bloqué, géré ou ignoré, l'appel fautif échoue avec EPIPE à la place.

0voto

Karl Points 386

Rien. Les données vont dans /dev/null.
P.S. Oh, oui, le programme recevra un signal, mais cela ne signifie pas qu'il devra se fermer.

0voto

psusi Points 35613

La réponse courte est que program1 meurt.

program1 reçoit un signal SIGPIPE lorsque le tuyau est rompu. Les programmes conçus pour être des démons en cours d'exécution gèrent généralement le signal et effectuent un nettoyage approprié, mais votre programme interactif typique ne le fait pas. L'action par défaut est de terminer le programme, donc pour la plupart, program1 sera simplement terminé.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X