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 ?
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 ?
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.
#!/usr/bin/env php
``
#!/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é.
``
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.
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é.
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.