When piping input from one program to another, what happens to the original program if the program receiving output is killed?

Question

I am piping the output of a program like this using bash:

program1 | program2

If program2 is killed somehow (in my case by a PHP fatal error), what happens to the instance of program1?

Answer 1

It greatly depends on what program1 is. The software needs to be able to handle (or ignore) a SIGPIPE signal. program1 will be responsible for handling the error - if the software is open source you should be able to discern what happens or if it traps/detects a SIGPIPE signal. If the software doesn't do anything special with streams it will likely complete execution before passing on the results. I attempted a small example to show the point using two php scripts.

program1

#!/usr/bin/env php
<?php

@unlink('program1.out');

for( $i = 0; $i < 10; $i++ )
{
    // This goes to either the buffer or whoever is next in the pipe
    echo $i . PHP_EOL;
    // Put everything in a file so we can see what Program1 actually did
    file_put_contents('program1.out', $i . PHP_EOL, FILE_APPEND);   
}

// All done! Cap off the file
file_put_contents('program1.out', 'Fin', FILE_APPEND);

program2

#!/usr/bin/env php
<?php

// We're taking inputs and just redirecting them to program2.out
// but to make it fun I'll throw an error half way through
// because I'm malicious like that

@unlink('program2.out');

$pipe_input = file("php://stdin");
$pipe_total = count($pipe_input);
$stop = rand(0, $pipe_total - 1);

echo "I'll be stopping at $stop" . PHP_EOL;

foreach( $pipe_input as $key => $input )
{
    if( $key == $stop )
    {
        file_put_contents('program2.out', 'Dead!', FILE_APPEND);
        die(1);
    }

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

When you execute ./program1 | ./program2 you'll get two .out files one for each program. In the example I ran I got the following files:

0
1
2
3
4
5
6
7
8
9
Fin

And for program2.out

0
1
2
3
4
Dead!

The first program will execute and pass it's contents to the second. You'll notice that the first program's .out file has a full set of numbers and the second only contains a set of that because it was killed off.

Answer 2

The pipe will be broken and the program writing to the pipe will receive a SIGPIPE signal.

From GLIBC:

SIGPIPE Broken pipe. If you use pipes or FIFOs, you have to design your application so that one process opens the pipe for reading before another starts writing. If the reading process never starts, or terminates unexpectedly, writing to the pipe or FIFO raises a SIGPIPE signal. If SIGPIPE is blocked, handled or ignored, the offending call fails with EPIPE instead.

Answer 3

Nothing. Data goes to /dev/null. P.S. Oh, yes, the program will recieve a signal, but it doesn't mean it will have to close.

Answer 4

The short answer is that program1 dies.

program1 gets a SIGPIPE signal when the pipe is broken. Programs designed to be long running daemons usually handle the signal and do proper cleanup, but your typical interactive program does not. The default action is to terminate the program, so for the most part, program1 will just be terminated.