php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16548 exec or system a daemon will catch the port for this session
Submitted: 2002-04-11 08:27 UTC Modified: 2003-02-13 19:54 UTC
Votes:7
Avg. Score:3.6 ± 0.7
Reproduced:4 of 5 (80.0%)
Same Version:1 (25.0%)
Same OS:1 (25.0%)
From: stefan dot marquardt at hagebau dot de Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 4.1.2 & 4.3.0 OS: RED HAT Linux 7.2
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.
Password:
Status:
Package:
Bug Type:
Summary:
From: stefan dot marquardt at hagebau dot de
New email:
PHP Version: OS:

 

 [2002-04-11 08:27 UTC] stefan dot marquardt at hagebau dot de
This are my simple commands:
system("$DLC/bin/proserve $CADB/$DB 2>&1");                 
system("exec $DLC/bin/_mprshut $CADB/$DB -C watchdog 2>&1");


The first command works fine but the second hangs the actual httpd session.
It executes o.k. but tries to get the actual webserver process:
[root@linux datenbank]# lsof | grep www                                        
httpd     30824 root   16u  IPv4      28772                  TCP *:www (LISTEN)
httpd     30825 root   16u  IPv4      28772                  TCP *:www (LISTEN)
httpd     30826 root   16u  IPv4      28772                  TCP *:www (LISTEN)
httpd     30827 root   16u  IPv4      28772                  TCP *:www (LISTEN)
httpd     30828 root   16u  IPv4      28772                  TCP *:www (LISTEN)
httpd     30829 root   16u  IPv4      28772                  TCP *:www (LISTEN)
httpd     30831 root   16u  IPv4      28772                  TCP *:www (LISTEN)
httpd     30835 root   16u  IPv4      28772                  TCP *:www (LISTEN)
_mprshut  31169 root   16u  IPv4      28772                  TCP *:www (LISTEN)

This process is the parent of 1:
[root@linux datenbank]# ps -ef | grep 31169                                     
root     31169     1  0 13:14 ?        00:00:00 /home/dlc83e/bin/_mprshut /home/
                                                                                
[root@linux datenbank]# ps -ef | grep 30835                                     
root     30835 30824  0 10:59 ?        00:00:00 /usr/local/apache/bin/httpd     

Then my actual session of my IE hangs and i only can lose it.
The php script is ended because i got </body> and the IE loading bar vanished.
I can't restart the server because this process 31169 holds port 80 open. 

I use the same script on SCO, Reliant Unix and HP-UX11.
On HP-UX11 the _mprshut also listen on port 80 but on a different session because the website still reacts.
The apache server restart is impossible before killing this process manually.
              

Any ideas where i can search the problem ??

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-11 11:35 UTC] wez@php.net
Please read the docs about system().
System executes the process and waits for it to complete
before returning.
You need to append an & character to your command to cause
it to run in the background.

 [2002-04-11 11:37 UTC] wez@php.net
Hmm, on second thoughts, it sounds like your OS is broken.
Does the equivalent script written in perl do the same?
 [2002-04-11 11:46 UTC] stefan dot marquardt at hagebau dot de
Hi,

system("exec $DLC/bin/_mprshut $CADB/$DB -C watchdog 1>/dev/null 2>&1 &");

has the same effect!
_mprshut is a daemon that ended in a second.

Please notice: The script doesn't hungs the rest works fine after system.
I can't open any new page after accessing this script an
_mprshut listen on port 80.
On HP-UX the Apache still works fine with a listening
_mprshut.

Stefan
 [2002-04-11 11:55 UTC] wez@php.net
Try this:
system("exec $DLC/bin/_mprshut $CADB/$DB -C watchdog 2>&1 </dev/null");

 [2002-04-12 02:06 UTC] stefan dot marquardt at hagebau dot de
The same with:
system("exec $DLC/bin/_mprshut $CADB/$DB -C watchdog 2>&1
</dev/null");

This _mprshut needs no input.
(I mail this problem also to the developer of _mprshut,Progress Database.)
The rest of the php script finishes but i can't open a new page and have to close this session.
In the moment i have no further idea to separate this command from the actual www session.
I tried "at", that works but +1 minute is too late. :-(
 [2002-04-12 05:26 UTC] wez@php.net
Most likely _mprshut is forking but keeping some fd's open, or doing something else strange.
I can't see how this is PHP's fault (it just uses popen),
so I'm marking this as bogus.
As a workaround, don't use exec :-)
 [2002-04-12 07:04 UTC] stefan dot marquardt at hagebau dot de
>> As a workaround, don't use exec :-)

system("$DLC/bin/_mprshut $CADB/$DB -C watchdog 2>&1
</dev/null");

has the same effect.
:-(
 [2002-04-15 08:48 UTC] stefan dot marquardt at hagebau dot de
>system(" ( $DLC/bin/_mprshut $CADB/$DB -C watchdog >/dev/null 2>&1 </dev/null )&");

>That should run the command in a sub-shell, and might solve this strange
problem.

>Also, have you tried enabling the sigchild handler?
./configure --help | grep sigchild


Nothing helps.
The developer of _mprshut can reproduce the same effect under IS(NT).
 [2002-04-17 06:04 UTC] stefan dot marquardt at hagebau dot de
New information:

I use now a cgi-bin version from php (before it was compiled into apache).
If i start the script frist time it runs perfect and ended.
(i see no php process).
After that i can open any html pages without problem.
If i try to open any php page in the same session it hungs.
I can see the php process ans strace shows this:
flock(3, LOCK_EX

Is there a possibilty for debugging php itself ?

I compiled not enable-debug but what can i do with that ?
 [2002-04-17 07:23 UTC] stefan dot marquardt at hagebau dot de
Without session.auto_start = 0 it works without problem !
(it was 1 but i use it)

[root@linux /tmp]# fuser sess*                             
sess_e2b04b5ddbae91f2c52fd86e808565f5: 20658 20661 20664 20667
[root@linux /tmp]# ps -ef | grep 20658
root     20658     1  0 12:15 ?        00:00:00 /home/dlc83e/bin/_mprshut /home/
root     20672 12474  0 12:15 pts/1    00:00:00 grep 20658                      

_mprshut access the session file in /tmp !

How can this happen ?
 [2002-04-17 10:01 UTC] stefan dot marquardt at hagebau dot de
Now it's 100% true:
Without session.auto_start = 0 it works also with apache with php compiled.

So i can't use session variables.
Has anybody interest to solve the problem ?
I know not much from C.

On which side is the error ? PHP or _mproshut (Progress) ?
 [2002-04-18 09:39 UTC] sniper@php.net
Please try PHP 4.2.0RC4 from http://www.php.net/~derick/

 [2002-04-18 10:30 UTC] stefan dot marquardt at hagebau dot de
Sorry !
PHP/4.2.0RC4 has the same problem with _mprshut and session.auto_start = 1.

httpd and _mprshut acces /tmp/sess_*
 [2002-04-23 19:55 UTC] sniper@php.net
This should be fixed in CVS. Please try the latest cvs snapshot from http://snaps.php.net/ and make sure the
Revision of ext/session/mod_files.c is 1.74

--Jani

 [2002-04-24 07:45 UTC] stefan dot marquardt at hagebau dot de
Found new error in latest cvs:
This line
system("$SDHAG/ha-server $DB $CADB $CABI 1 $SDHAG 2>&1",$ret); 

has 0 100% as returncode i put an echo before exit 0!
With older php there was now error.
 [2002-04-24 07:49 UTC] stefan dot marquardt at hagebau dot de
Sorry i forgot that now _mprshut doesn't blocks the Apache.
But _mprshut is still listening on port 80 after running
this script ha-server (_mrshut is called in it):
_mprshut   3989 root   16u  IPv4  85958  TCP *:www (LISTEN)
(output from lsof)

PHP Version 4.3.0-dev
 [2002-09-26 10:43 UTC] wez@php.net
Related to #15642 and #15529. 
 [2002-12-07 01:54 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2003-01-30 09:13 UTC] sean@php.net
Re-opened.

I this has been happening to us, as well (php4.2.2 / CGI (command line) / RH7.3 x86). We are unable to reproduce this reliable, but our error trap is showing many "unable to fork" errors on exec calls.

S

 [2003-02-13 19:54 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 05:01:28 2024 UTC