[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."
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.
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
Created attachment 146793 [details] popen / pclose test (fails with glibc-2.5-8.fc6) pclose does not return -1.
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.
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