php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51160 Exec family of functions runs a script piped into 'head' too until script end
Submitted: 2010-02-26 21:15 UTC Modified: 2010-05-17 11:21 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: poehler at interworx dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 5.2.13 OS: CentOS 5.4
Private report: No CVE-ID: None
 [2010-02-26 21:15 UTC] poehler at interworx dot com
Description:
------------
See reproduce code and expected / actual result sections for details.

Short story is when exec'ing with a pipe to 'head', we're getting unexpected results.

I'm aware this may be 'correct' behavior, by some definition, but for the life of me I can't figure out where this behavior is documented, if that is the case.  So if that is the case, please point me in the right direction, if you could be so kind.



Reproduce code:
---------------
test.sh:
=================
#!/bin/sh

for i in 1 2 3 4 5
do
   echo "Welcome $i times"
   sleep 1
done
==================


test.php:
==================
<?
passthru( '/bin/sh test.sh | head -n1' );

==================




Expected result:
----------------
Here is the output of running the same command at the shell, which is correct.
==================
[root@me]# time /bin/sh test.sh | head -n1
Welcome 1 times

real    0m1.030s
user    0m0.002s
sys     0m0.027s
==================
And I would expect identical (save minor timing differences) when test.php is run.

Actual result:
--------------
[root@me]# php test.php
Welcome 1 times
test.sh: line 5: echo: write error: Broken pipe
test.sh: line 5: echo: write error: Broken pipe
test.sh: line 5: echo: write error: Broken pipe
test.sh: line 5: echo: write error: Broken pipe

real    0m5.191s
user    0m0.002s
sys     0m0.038s

Note that this took 5 seconds instead of 1.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-26 21:22 UTC] binarycleric at gmail dot com
Just wanted to confirm that this also occurs on Mac OS 10.6 using version PHP 5.3.0.
 [2010-05-17 11:21 UTC] mike@php.net
-Status: Open +Status: Bogus
 [2010-05-17 11:21 UTC] mike@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

$ cat 51160.php 
<? 

pcntl_signal(SIGPIPE, function() { exit; });

passthru ("/bin/sh 51160.sh | head -n1");
 [2010-12-07 21:57 UTC] sirjava at gmail dot com
I'm confused.  If the exec family of functions is designed to execute something as if executed from a shell, and the command executes properly from a shell, but not in php... how is this not a php bug?
 [2012-01-18 21:59 UTC] burek021 at gmail dot com
I also have this issue. I've tried to test a simple example on several of our web hosting machines and all of them have this issue present.

Simple test. Create a php file (test.php) with this content:
==================
<?php
shell_exec('ls | ls | ls | ls' );
==================
and then run: php -f test.php 2>&1
you should get the error like: ls: write error: Broken pipe
almost every time you run that command.

I'm not sure what's the reason for this, but I'm pretty sure it's the bug, since the bash/sh doesn't ever raise that error no matter how many ls'es we put into the pipe.
 [2012-01-19 12:26 UTC] burek021 at gmail dot com
Just to say, my problem somehow got misteriosly solved. I don't know exactly what was the culprit, but I know I've messed around with ulimit and with apache2.conf:
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers     100
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>
More details here (if needed): http://www.linuxquestions.org/questions/showthread.php?p=4577927
 [2012-05-07 08:39 UTC] mrvanes at gmail dot com
I was encountering a similar problem too and for some reason Mike's hint 
(registering an empty/exit function on the SIGPIPE signal) solved the problem for 
me.
The only problem I now have is racking my brains over WHY?! Is this discussed 
somewhere so I can read up on the given solution?
 [2012-05-09 07:09 UTC] mrvanes at gmail dot com
I must correct: the SIGPIPE sighandler does suppress the message but does not 
solve the problem! The command that generates the broken pipe fails.
 [2012-05-09 09:27 UTC] mrvanes at gmail dot com
Ok, so I finally think to have cracked the problem:
This seem to be the equivalent of exec('cmd', &$output) that does not create a 
broken pipe:

$p = proc_open("ls | ls | ls | ls | ls | ls | ls | echo `date` >> foobar | ls",
  array(
    array("pipe","r"),
    array("pipe","w"),
    array("pipe","w")
  ),
  $pipes
);
while (($buffer = fgets($pipes[1])) !== false) $output[] = trim($buffer);
foreach ($pipes as $pipe) fclose($pipe);
if (isset($output)) print_r($output);

There is no broken pipe and the file foobar now contains the output of date.
 [2012-06-05 09:14 UTC] mrvanes at gmail dot com
The above proc_open solution does work (better) for the `ls | ls | ls | ls | ls` 
test case, but not my real-world problem. This is becoming a nasty bug(?) to work 
around.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 13:01:28 2024 UTC