php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #25480 All exec, passthru, system, shell execution commands fail intermittently.
Submitted: 2003-09-10 18:10 UTC Modified: 2003-10-21 21:19 UTC
From: colin at grandecom dot com Assigned:
Status: Not a bug Package: Program Execution
PHP Version: 4.3.3 OS: Solaris 2.8
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: colin at grandecom dot com
New email:
PHP Version: OS:

 

 [2003-09-10 18:10 UTC] colin at grandecom dot com 
Description:
------------
At certain times (no discernible load, nor any unusually
high memory or swap usage, etc.) all shell exec commands
fail.  Typically it will last a short period of time, and
then all commands work fine.  Restarting apache does not
appear to cure or improve the situation.  Below are my
particulars.

My configure line:
./configure --with-apxs=/usr/local/apache/bin/apxs --with-oracle=/opt/oracle --with-snmp=/usr/local --with-curl=/opt --with-gd --with-zlib-dir=/usr/local/lib

Other information:
Sun E250, 2x296mhz, 1024MB RAM, gcc 2.95.2

Changes to php.ini from php.ini-dist:
register_globals = On

Here are some error examples from various execs:
Warning: shell_exec(): Unable to execute 'nslookup -timeout=3  10.130.0.1 2>/dev/null' in /usr/local/apache/htdocs/my.php on line 39
Warning: system(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t 250 10.130.2.163] in /usr/local/apache/htdocs/my.php on line 79
Warning: passthru(): Unable to fork [/opt/qip/usr/bin/qping -v -r 3 -t 250 10.130.2.163] in /usr/local/apache/htdocs/my.php on line 78

Reproduce code:
---------------
echo "<pre>"; system("ping -s $ip 56 10"); echo "</pre>";

Expected result:
----------------
Warning: system(): Unable to fork [ping -s 10.130.2.163 56 10] in /usr/local/apache/htdocs/ping.php on line 55

Actual result:
--------------
Command simply doesn't execute, program continues without
a problem or error.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-09-10 20:06 UTC] sniper@php.net 
Is "safe_mode" enabled?
 [2003-09-10 20:07 UTC] sniper@php.net 
Also, did this happen with previous PHP versions? If not, which was the previous version you had?
 [2003-09-10 21:05 UTC] colin at grandecom dot com 
safe_mode = Off

It is only happening to me with 4.3.3 - on this particular
machine I upgraded from 4.3.1 yesterday to fix an snmp bug,
and the problem start happening today (I'd run 4.3.1 
without any exec issues for several weeks prior.)  In
retrospect, this definitely should have been mentioned in
my initial bug report.  Sorry about that.
 [2003-10-16 09:25 UTC] bk at galaxy dot net 
I'm seeing the same thing.  I get shell_exec() to fail
ever since upgrading to 4.3.3 as well as popen() within
the sendmail module of pear.

I'm wondering if this has something to do with the
solaris limit of 256 file descriptors in FILE streams
and running out of them.  But it is strange that this
didn't start until I upgraded to 4.3.3.
 [2003-10-16 10:28 UTC] bk at galaxy dot net 
Sure enough, when I reduce the file descriptors down (it was over 400), the intermittent problems went away.  I
eliminated the ErrorLog for the virtual hosts to knock
the file descriptors down to 200 and it seems to work
consistently (so far).
 [2003-10-16 13:17 UTC] colin at grandecom dot com 
I only had mine (ulimit -n) set to 256, and I tried upping it to 1024 with no discernible result.  My system is an internal one, and has no customer vhosts - just a couple of name vhosts, referencing about 4 logs total.  I'm not sure why _dropping_ your number of file descriptors would fix the problem - if anything, that would make it worse it would seem.   I have to say that I doubt your problem is gone for good.
 [2003-10-18 11:14 UTC] bk at galaxy dot net 
I guess you misunderstood.  I reduced the number of file
descriptors in use to make sure fd value is < 256.

In the FILE* structure, which is what fopen(), popen(), etc
uses, they only have a "char" to hold the file descriptor.
fopen() and popen() will fail if the file descriptor it gets
assigned is >= 256.  This problem goes away in 64 bit mode,
but not many people are using that yet.

Sure enough, all my problems with shell_exec() have gone
away since eliminating all the ErrorLog lines from my web
server.  If you run "pfiles" on your httpd process, you'll
see the ulimit as well as how many file descriptors you have
open.  If this value goes above 255, you'll start seeing
intermittent exec failures.  Its intermittent since some
fd's less than 256 may get closed and reused to allow an
exec to work, however once they're all full in the lower
numbers, you'll fail again.
 [2003-10-18 23:11 UTC] sniper@php.net 
Given the above comment, this is not PHP bug.
 [2003-10-21 21:19 UTC] colin at grandecom dot com 
Yes, I guess I thought you meant you reduced the number of system file descriptors.

For what its worth though, my system is set w/rlimit 1024 and with 4.3.3, it would continually fail the exec commands after mere hours of operation.  I did not check how many FDs were in use with Apache at the time, but for the purposes of comparison, my server (which has been running 4.3.1 flawlessly non-stop since 09/08, or about a month and a half) is currently using 21 descriptors.

So my guess is that 4.3.3 has some kind of problem releasing  ones that have already been used?
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 01:00:01 2025 UTC