|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27201 exec does not wait for completion of cmd
Submitted: 2004-02-10 03:45 UTC Modified: 2004-02-13 08:45 UTC
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: lars at erhardsen dot dk Assigned:
Status: Closed Package: Program Execution
PHP Version: 4.3.4 OS: debian woody
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: lars at erhardsen dot dk
New email:
PHP Version: OS:


 [2004-02-10 03:45 UTC] lars at erhardsen dot dk
I think, I have a similar problem as #11023 - where exec() does not wait for program completion.

The scenary is: Linux 2.4.22, Apache 2.0.48, PHP 4.3.4 on a Pentium 4,
2.4ghz, 512 mb ram

The page continues without the 'output' from exec thus leaving an
incomplete page. If I press f5/refresh, some times it works, other times
it does not work.

I have also placed sleeps between commands to ensure it works well, but imho this should not be nescessary - as this  "bug" does not appear on a slower machine.

My php config: 
./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-gd=/usr/local --with-pdflib=/usr/local --with-mysql
--with-config-file-path=/etc/apache2 --with-session --with-zlib-dir=/usr
--with-png-dir=/usr/lib --with-freetype-dir=/usr --with-jpeg-dir=/usr
--with-tiff-dir=/usr --with-system-regex=yes --enable-debug=no
--with-xml --with-imap-ssl=/usr/local/imap-2002d --enable-exif
--with-openssl --with-gettext --enable-ftp --enable-sysvsem
--enable-sysvshm --enable-calendar --enable-bcmath --enable-sockets
--enable-track-vars --with-mcrypt --enable-gd-native-ttf
--enable-mbstring --enable-gd-native-ttf

My Apache config:
./configure --enable-ssl --enable-rewrite --enable-so --enable-info
--enable-suexec --with-suexec-caller=nobody --enable-dav 

Reproduce code:
system ( "hostname" );
echo " | ";

$a = exec ( "uptime" );
$b = split(',', $a);
$c = split('up', $b[0]);
$d = split(':', $b[3]);

echo $c[1] . " | " . $d[1] . ", " . $b[4] . ", " . $b[5];

Expected result:
maxmotor | 75 days | 0.00, 0.00, 0.00 

Actual result:
Some times, nothing is returned


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-10 04:29 UTC]
If hyperthreading is available and on, turn it off and 
then try the same thing again. It's known to cause some 
problems with older linux kernels.

 [2004-02-10 04:35 UTC] lars at erhardsen dot dk
HT is available, but not enabled. The kernel is compiled as UNIprocessor (or what it's called)
 [2004-02-10 07:59 UTC]
Please try using this CVS snapshot:
For Windows:

And use this configure line (and run the script with sapi/cli/php binary):

# ./configure --disable-all --disable-cgi --enable-debug

 [2004-02-10 08:56 UTC] lars at erhardsen dot dk
With the new source, and the following code, I cannot reproduce the error. 
My concern is now, that it is caused by apache2 - but the strange thing is, that on the slow machine, this error doesn't occur.

The apache2handler seems broken( or maybe I cannot compile it  - error 40 ;o)) so I cannot check it with the apache server...

The code:
$i = 0;
while ($i < 10000) {

echo $i . ": ";
system ( "hostname" );
echo " | ";

$a = exec ( "uptime" );
$b = split(',', $a);
$c = split('up', $b[0]);
$d = split(':', $b[3]);

echo $c[1] . " | " . $d[1] . ", " . $b[4] . ", " . $b[5];
echo "\r\n";
 [2004-02-10 17:56 UTC]
Can you produce the problem with 4.3.4 CLI binary?
What apache2 error? Compile time? or what??

 [2004-02-11 01:55 UTC] lars at erhardsen dot dk
Sorry, the last posting was a little un-informative.

I tried compiling the cvs snapshot as cli, and set up a program loop with the contents stated in my previous posting. I let it run to around 5000, and no error appeared.

I compiled the cli executeable with "./configure --disable-all --disable-cgi --enable-debug".

I then tried to compile the source with --with-apxs2=path - which ended up with the following error:
/home/admin/debug/php4-STABLE-200402101230/sapi/apache2handler/sapi_apache2.c: In function `php_apache_request_ctor':
/debug/php4-STABLE-200402101230/sapi/apache2handler/sapi_apache2.c:432: `f' undeclared (first use in this function)
/debug/php4-STABLE-200402101230/sapi/apache2handler/sapi_apache2.c:432: (Each undeclared identifier is reported only once
/debug/php4-STABLE-200402101230/sapi/apache2handler/sapi_apache2.c:432: for each function it appears in.)

I'm currently considering to replace Apache2 with Apache 1.3.xx - to see, if it could help.
 [2004-02-11 02:53 UTC]
If you want it stable, use 1.3.29, setting it to feedback to see if it works with apache 1.3.

 [2004-02-11 08:17 UTC] lars at erhardsen dot dk
Now this appears in the apache error-log:

sh: /hostname: No such file or directory
sh: /uptime: No such file or directory

How can this be?
 [2004-02-11 12:41 UTC]
Please try using this CVS snapshot:
For Windows:

The apache2 build bug has been fixed. 
As far as the exec() situations I've just tried to 
replicate the bug with the while() example and was unable 
to do so. 
 [2004-02-12 02:39 UTC] lars at erhardsen dot dk
Hi, I've just compiled the source, you supplied. I'm watching the errorlog closely today and will let you know if there's good or bad news :o)

Oh, btw, the openssl part of this source php4-STABLE-200402120630 throws an error on startup when I use --with-openssl in the config

I'm really grateful for all your help! :o)
 [2004-02-13 03:11 UTC] lars at erhardsen dot dk
Well, after having the 4.3.5RC3-dev running for the last 24h it seems that the error is no longer with us.

What did you fix?
 [2004-02-13 08:45 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

User reports that the problem has been fixed. 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 16 02:01:29 2024 UTC