Bug #29107 [Com]: Parent: child process exited with status 3221225725
| From: | nickzipse at jabico dot com | Date: | Mon, 22 Oct 2012 21:54:27 +0000 |
| Subject: | Bug #29107 [Com]: Parent: child process exited with status 3221225725 | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-174230@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=29107&edit=1
ID: 29107
Comment by: nickzipse at jabico dot com
Reported by: bart at mediawave dot nl
Summary: Parent: child process exited with status 3221225725
Status: Closed
Type: Bug
Package: Apache2 related
Operating System: Win2k
PHP Version: 4.3.7
Block user comment: N
Private report: N
New Comment:
I'm getting the exact if not very similar error:
[Mon Oct 22 14:49:54 2012] [notice] Parent: child process exited with status
3221225725 -- Restarting.
[Mon Oct 22 14:49:54 2012] [notice] Digest: generating secret for digest
authentication ...
[Mon Oct 22 14:49:54 2012] [notice] Digest: done
[Mon Oct 22 14:49:55 2012] [notice] Apache/2.2.21 (Win32) mod_ssl/2.2.21
OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming
normal operations
[Mon Oct 22 14:49:55 2012] [notice] Server built: Sep 10 2011 11:34:11
[Mon Oct 22 14:49:55 2012] [notice] Parent: Created child process 8448
[Mon Oct 22 14:49:56 2012] [notice] Digest: generating secret for digest
authentication ...
[Mon Oct 22 14:49:56 2012] [notice] Digest: done
[Mon Oct 22 14:49:56 2012] [notice] Child 8448: Child process is running
[Mon Oct 22 14:49:56 2012] [notice] Child 8448: Acquired the start mutex.
[Mon Oct 22 14:49:56 2012] [notice] Child 8448: Starting 150 worker threads.
[Mon Oct 22 14:49:56 2012] [notice] Child 8448: Starting thread to listen on
port 443.
[Mon Oct 22 14:49:56 2012] [notice] Child 8448: Starting thread to listen on
port 443.
[Mon Oct 22 14:49:56 2012] [notice] Child 8448: Starting thread to listen on
port 80.
This happens sporadically without any consistency of the error.
The page I try to view will randomly break and say the webserver is down.
I tried adding the return date() in the pear library but had no luck.
Any help will be much appreciated!
Previous Comments:
------------------------------------------------------------------------
[2005-03-15 22:47:27] bart at mediawave dot nl
Argh... I can't believe that it would come as far as spamming the PHP bugs database! I'm
re-opening this bug asuming somebody will want to remove the spam? If not, let me know. I'll
leave them closed next time.
------------------------------------------------------------------------
[2004-11-22 14:07:19] jorton@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
------------------------------------------------------------------------
[2004-08-13 05:20:02] loye dot young at iycc dot net
If you have the PEAR Date package installed, this may be the problem:
There is a command in a Pear function that tries to write information to the server. Some Windows
installations and Unix servers with strict Safe Mode options enabled do not allow this. You can fix
this yourself however.
Open the file lib/pear/Date/TimeZone.php in a text editor. Go to line 247. You should be in a
function named 'inDaylightTime()'. Add this line: return date("I"); at the very
top of the function. It should now look like this:
function inDaylightTime($date)
{
return date("I");
$env_tz = "";
if(getenv("TZ"))
$env_tz = getenv("TZ");
putenv("TZ=".$this->id);
$ltime = localtime($date->getTime(), true);
putenv("TZ=".$env_tz);
return $ltime['tm_isdst'];
}
This should stop the error. Perhaps in the future, the Pear team will supply a work around.
See if that fixes it and let everyone know.
------------------------------------------------------------------------
[2004-07-23 15:55:42] bart at mediawave dot nl
I don't think that's my problem. I'm having the problem at my testing server where,
most of the time, I'm the only client. So ,if persistent connections work like they should I
guess, in my case, there's only one conection there.
------------------------------------------------------------------------
[2004-07-23 15:34:59] super_freax at hotmail dot com
It says in the PHP-manual for child operations that :
This means that for every child that opened a persistent connection will have its own open
persistent connection to the server. For example, if you had 20 different child processes that ran a
script that made a persistent connection to your SQL server, you'd have 20 different
connections to the SQL server, one from each child.
Note, however, that this can have some drawbacks if you are using a database with connection limits
that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous
connections, and in the course of a busy server session, 17 child threads attempt to connect, one
will not be able to. If there are bugs in your scripts which do not allow the connections to shut
down (such as infinite loops), the database with only 16 connections may be rapidly swamped
======
So it might be the database that has no more connections left ?
My Config is :
WinXPProSP1 (NTFS Formatted)
Apache version 2.0.49
MySQL 4.0.18 with MyODBC 3.51 and winMYSQLadmin 1.4
PHP 4.3.6 with Pear 1.3.1 ,Smarty 2.5.0 ,Zend Opt. 2.5.0 , Dbg 2.16.3, TCL 8.4.5 with TK 8.4 and
Vtcl 1.6.0
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=29107
--
Edit this bug report at https://bugs.php.net/bug.php?id=29107&edit=1