Bug 175167 - Problem with 'popen' called via php
Problem with 'popen' called via php
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
Application at http://www.cacti.net/
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-07 01:53 EST by Reuben Farrelly
Modified: 2008-05-06 20:18 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:18:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
popen / pclose test (fails with glibc-2.5-8.fc6) (418 bytes, text/plain)
2007-01-28 17:58 EST, Sami Farin
no flags Details

  None (edit)
Description Reuben Farrelly 2005-12-07 01:53:09 EST
[Please excuse the vagueness of this report, I am filing this bug report based
on my experience and what I have discovered with the developer of a piece of
software I use, I'm not a developer myself and NOT a programmer]

This bug report is being filed based on the behaviour of a php application which
makes use of the 'popen' function and which has been suggested by the
application developer, to be a glibc issue.

The application is cacti, which is a php script based application used to gather
performance statistics on a variety of different targets.  See
http://www.cacti.net/ for more information about what this software is used for.

The problem is occuring with a script which does the polling every few minutes.
 If I execute this script as a single thread per process it works fine.  If
however I change it to attempt to execute three threads per process I get this
repeated over and over:

ACTID: Host[0] ERROR: The function was interrupted before any of the selected
events occurred and before the timeout interval expired.
CACTID: Host[0] ERROR: The POPEN timed out
CACTID: Host[0] DS[66] WARNING: Result from SCRIPT not valid. Partial Result: ...
CACTID: Host[1] ERROR: The function was interrupted before any of the selected
events occurred and before the timeout interval expired.
CACTID: Host[1] ERROR: The POPEN timed out
CACTID: Host[1] DS[3] WARNING: Result from SCRIPT not valid. Partial Result: ...
CACTID: Host[0] ERROR: The function was interrupted before any of the selected
events occurred and before the timeout interval expired.
CACTID: Host[0] ERROR: The POPEN timed out

The script is failing on the popen immediately - either the timeout is
incredibly small or else something is broken.

In terms of the behaviour I am seeing, if this application is run with a single
thread it works fine, but if the script is run with more than one thread
(normally three) the message above is displayed and some of the polls never return.

This problem does not affect FC4+updates but with the same application code and
current FC5/rawhide it's a no-op.

HTTP access to the application source code is at
http://svn.cacti.net/cgi-bin/viewcvs.cgi/branches/BRANCH_0_8_6/cacti/ - it is
the poller.php process which is executed via cron every 5 mins and is the one
that shows the problem up.

The developer of the software suggested that this is a bug in glibc (rather than
php) which is why I am filing it here.  To quote him when I asked whether this
was a php problem he said: "No, I would say GLIBC.  The reason for this is that
the POPEN in Cactid failed as well indicating a library call completely separate
from PHP."
Comment 1 Jakub Jelinek 2005-12-07 03:59:16 EST
php wrappers around popen are very thick and it is much more likely the problem
is in there than in glibc.  If you say the difference is between FC4+updates and
FC5, then also I can say there have been no popen related changes in glibc
whatsoever.
Comment 2 Sami Farin 2007-01-28 17:53:57 EST
Let's check it out.
I noticed mixmaster uses popen and pclose, and tries to execute
/usr/lib/sendmail, but 
doesn't notice it fails.

man page says pclose returns -1 if it fails.
now it returns 32512.

$ env - /usr/bin/strace -vf -eexecve ./a.out /usr/lib/sendmail
execve("./a.out", ["./a.out", "/usr/lib/sendmail"], []) = 0
Process 16273 attached
popen=0x896a008: Success
Process 16272 suspended
[pid 16273] execve("/bin/sh", ["sh", "-c", "/usr/lib/sendmail"], []) = 0
[pid 16273] execve("/usr/lib/sendmail", ["/usr/lib/sendmail"],
["PWD=/home/safari/c", "SHLVL=1", "_=/usr/lib/sendmail"]) = -1 ENOENT (No such
file or directory)
sh: /usr/lib/sendmail: No such file or directory
Process 16272 resumed
Process 16273 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
pclose=32512: Success
Process 16272 detached
Comment 3 Sami Farin 2007-01-28 17:58:08 EST
Created attachment 146793 [details]
popen / pclose test (fails with glibc-2.5-8.fc6)

pclose does not return -1.
Comment 4 Bug Zapper 2008-04-03 12:40:18 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 5 Bug Zapper 2008-05-06 20:18:35 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.