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.

Hmm, on second thoughts, it sounds like your OS is broken.
Does the equivalent script written in perl do the same?

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

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

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. :-(

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 :-)

>> As a workaround, don't use exec :-)

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

has the same effect.
:-(

>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).

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 ?

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 ?

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) ?

Please try PHP 4.2.0RC4 from http://www.php.net/~derick/

Sorry !
PHP/4.2.0RC4 has the same problem with _mprshut and session.auto_start = 1.

httpd and _mprshut acces /tmp/sess_*

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

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.

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

Related to #15642 and #15529. 

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

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

Please try using this CVS snapshot:

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

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.