Your message dated Mon, 11 Apr 2011 00:10:34 +0200
with message-id <[email protected]>
and subject line Re: [php-maint] Bug#431799: Bug#431799: php5-cgi: PHP fastcgi
with PHP_FCGI_CHILDREN doesn't kill children when parent is killed
has caused the Debian Bug report #431799,
regarding php5-cgi: PHP fastcgi with PHP_FCGI_CHILDREN doesn't kill children
when parent is killed
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
431799: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431799
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: php5-cgi
Version: 5.2.0-8+etch4
Severity: important
Tags: patch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoting from: http://bugs.php.net/bug.php?id=40286
- --
Context:
When running PHP in FastCGI mode with a fastCGI apache module (such a
mod_fcgid), all is running fine when PHP_FCGI_CHILDREN unset : only 1
process spawned. When using PHP_FCGI_CHILDREN=n, the PHP parent process
forks n childs, and the parent acts as a manager between the child
processes, wait()ing to respawn them if they are killed or exit. The
problem happens when the FastCGI process manager handled by the apache
module has to kill the parent PHP process (it only knows the parent's
PID) for any reason such as idle timeout, max lifetime, etc.
Problem:
While the PHP parent process is properly killed by the FastCGI process
manager, the children aren't killed, but instead stay alive, waiting for
a new request which will never come (because the socket shared with the
parent is removed at the same time parent is killed).
- --
At the end of the PHP bug report there's a patch.
PHP4 Is also affected (and I guess, but can't confirm, lenny's PHP4/5 are also
affected).
This bug causes a lot useless php[4|5]-cgi processes to remain on memory and
thus consuming resources.
I hope a fixed php[4|5]-cgi package can make into etch's r1 or even before (if
possible).
- -- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (100, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGjC3iYy49rUbZzloRAmUBAJ9wrP8K1x1PwjysFsFTAhLTIvnHRQCfQPAd
YnRVnKzAjwVS3Kb+Su8NfLg=
=s/V3
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
Raphael,
this is your bug... I am closing it now, since it's been reported
against some ancient version of PHP. Feel free to reopen it if you
feel like fixing it :).
O.
2007/8/22 Ondřej Surý <[email protected]>:
> Raphael Geissert píše v St 04. 07. 2007 v 18:31 -0500:
>> At the end of the PHP bug report there's a patch.
>
> I don't believe that attached patch fixes that particular problem.
> It only eliminates one extra pointer to memory, which is only cosmetics
> change to code and not any change in functionality.
>
> Correct fix would be to use non-blocking IO. Or use select(2) on that
> descriptor to not block when no data is available.
>
> But of course I could be wrong and this is The Right Fix(tm).
>
> Ondrej
> --
> Ondřej Surý <[email protected]> *** http://blog.rfc1925.org/
> Kulturní občasník *** http://www.obcasnik.cz/
> Nehoupat, prosím *** http://nehoupat.blogspot.com/
>
>
>
>
> _______________________________________________
> pkg-php-maint mailing list
> [email protected]
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
--
Ondřej Surý <[email protected]>
--- End Message ---
