Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 3 down vote accepted

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.


#!/usr/bin/env php


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


#!/usr/bin/env 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


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

    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:


And for program2.out


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.

share|improve this answer
Thanks for your answer. :) Your example only partly relates to my actual problem, which I didn't really discuss in the question (but the use case is probably more spread). I am piping ffmpeg error/info/progress output to a php script, which I am reading char by char, while I think your example reads until EOF. Since ffmpeg will run for hours, I need to know exactly what happens. I think it is terminated by SIGPIPE actually. :) – Max Apr 27 '11 at 12:55
@Max In that case it depends on how ffmpeg handles SIGPIPE. A workaround would be to have ffmpeg pipe it's STDERR to a file and your php script tail or chunk/process the file that way you don't have long running php files which are not quite optimized for long running execution. – Marco Ceppi Apr 27 '11 at 13:06
true, but I am not running PHP it a web-based context. I am using at to execute php. :) I actually want to shut-down ffmpeg if something happens during the log-script execution, since I want the execution to be in a known state. But you clarified alot, thanks. :) – Max Apr 27 '11 at 13:16

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


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.

share|improve this answer
What's the default action for something receiving a SIGPIPE signal? Eg if an application doesn't handle it directly, does something else come along and nuke it or will it just carry on pipeless? – Oli Apr 27 '11 at 12:26

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.