Bug #40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
Edit report at http://bugs.php.net/bug.php?id=40286&edit=1 ID: 40286 Comment by: jason at backup-technology dot co dot uk Reported by:gabriel at oxeva dot fr Summary:PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed Status: No Feedback Type: Bug Package:CGI related Operating System: Linux 2.6 PHP Version:5.2.0+ Assigned To:dmitry Block user comment: N New Comment: We're experiencing this issue with 5.2.14 and also 5.3.3. On 5.2.14 the strace of the hanging processes with parent ID 1 left behind show this: Process 21330 attached - interrupt to quit accept(0, It hangs on that and if we interrupt it shows: Process 21330 attached - interrupt to quit accept(0, Running a gdb (with debug symbols) and attaching to the process and running "bt" we get: (gdb) bt #0 0x00320c8d4530 in __accept_nocancel () from /lib64/libc.so.6 #1 0x0062abe8 in fcgi_accept_request (req=0x7fff3cb385b0) at /usr/src/debug/php-5.2.14/sapi/cgi/fastcgi.c:957 #2 0x0062c14f in main (argc=1, argv=0x7fff3cb3a758) at /usr/src/debug/php-5.2.14/sapi/cgi/cgi_main.c:1703 On the 5.3.3 (with no debug symbols) we have the following: (gdb) bt #0 0x0038936d4530 in __accept_nocancel () from /lib64/libc.so.6 #1 0x0063e0c3 in ?? () #2 0x0063ad2a in ?? () #3 0x00389361d994 in __libc_start_main () from /lib64/libc.so.6 #4 0x00421ec9 in _start () Hope this helps. Jason. Previous Comments: [2009-07-26 21:55:21] machochito at gmail dot com I have the same problem on CentOS 5.3 with php 5.2.9. Have someone solution to this problem? Thanks. [2009-07-22 20:45:21] bgross at mcw dot edu ... on second thought, after looking at my php.ini again, I think the major change was due to adding the line "session.gc_probability = 1". I believe this is set to "session.gc_probability = 0" by default in Debian [2009-07-22 20:14:41] bgross at mcw dot edu I'm not familiar with the inner-workings PHP, so I'm sorry if this is not relevant. I was experiencing a problem with php-cgi processes staying around and filling up my memory. After I added the line "cgi.fix_pathinfo=1" to my php.ini, the problem went away. I'm using PHP FastCGI 5.2.6 with Lighttpd 1.4.19 on Debian 5.0.2 Hope that's helpful [2009-07-02 03:41:27] porjo38 at yahoo dot com dot au The php 5.3.0 changelog states the following: "Fixed bug #40286 (PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed). (Dmitry)" I've just compiled php 5.3.0 under Centos5.3 with Apache2.2.3 + mod_fcgid2.2-4. The issue is still occuring for me. When I restart Apache, I usually end up with a bunch of php-cgi process with ppid of 1 (init), although it doesn't happen every time. [2009-05-16 03:43:15] scripts at topducks dot com I'm using php5.2.9 mod_fcgid, not using children method. Whenever I restart apache I get orphaned php processes. Without the cron job to check and kill them off they would waste a lot of memory. 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 http://bugs.php.net/bug.php?id=40286 -- Edit this bug report at http://bugs.php.net/bug.php?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: machochito at gmail dot com Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0+ Assigned To: dmitry New Comment: I have the same problem on CentOS 5.3 with php 5.2.9. Have someone solution to this problem? Thanks. Previous Comments: [2009-07-22 20:45:21] bgross at mcw dot edu ... on second thought, after looking at my php.ini again, I think the major change was due to adding the line "session.gc_probability = 1". I believe this is set to "session.gc_probability = 0" by default in Debian [2009-07-22 20:14:41] bgross at mcw dot edu I'm not familiar with the inner-workings PHP, so I'm sorry if this is not relevant. I was experiencing a problem with php-cgi processes staying around and filling up my memory. After I added the line "cgi.fix_pathinfo=1" to my php.ini, the problem went away. I'm using PHP FastCGI 5.2.6 with Lighttpd 1.4.19 on Debian 5.0.2 Hope that's helpful [2009-07-02 03:41:27] porjo38 at yahoo dot com dot au The php 5.3.0 changelog states the following: "Fixed bug #40286 (PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed). (Dmitry)" I've just compiled php 5.3.0 under Centos5.3 with Apache2.2.3 + mod_fcgid2.2-4. The issue is still occuring for me. When I restart Apache, I usually end up with a bunch of php-cgi process with ppid of 1 (init), although it doesn't happen every time. [2009-05-16 03:43:15] scripts at topducks dot com I'm using php5.2.9 mod_fcgid, not using children method. Whenever I restart apache I get orphaned php processes. Without the cron job to check and kill them off they would waste a lot of memory. [2009-01-21 23:34:39] xani666 at gmail dot com In my case that bug was happening on apache + php 5.2.8 + mod_fastcgi + mod_suexec with about ~20 sites (3-4 busy most time of day, other used from time to time) with fastcgi options -idle-timeout 240 -maxClassProcesses 1 and PHP_FCGI_CHILDREN=4 so processes died quite often. 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: bgross at mcw dot edu Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0+ Assigned To: dmitry New Comment: ... on second thought, after looking at my php.ini again, I think the major change was due to adding the line "session.gc_probability = 1". I believe this is set to "session.gc_probability = 0" by default in Debian Previous Comments: [2009-07-22 20:14:41] bgross at mcw dot edu I'm not familiar with the inner-workings PHP, so I'm sorry if this is not relevant. I was experiencing a problem with php-cgi processes staying around and filling up my memory. After I added the line "cgi.fix_pathinfo=1" to my php.ini, the problem went away. I'm using PHP FastCGI 5.2.6 with Lighttpd 1.4.19 on Debian 5.0.2 Hope that's helpful [2009-07-02 03:41:27] porjo38 at yahoo dot com dot au The php 5.3.0 changelog states the following: "Fixed bug #40286 (PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed). (Dmitry)" I've just compiled php 5.3.0 under Centos5.3 with Apache2.2.3 + mod_fcgid2.2-4. The issue is still occuring for me. When I restart Apache, I usually end up with a bunch of php-cgi process with ppid of 1 (init), although it doesn't happen every time. [2009-05-16 03:43:15] scripts at topducks dot com I'm using php5.2.9 mod_fcgid, not using children method. Whenever I restart apache I get orphaned php processes. Without the cron job to check and kill them off they would waste a lot of memory. [2009-01-21 23:34:39] xani666 at gmail dot com In my case that bug was happening on apache + php 5.2.8 + mod_fastcgi + mod_suexec with about ~20 sites (3-4 busy most time of day, other used from time to time) with fastcgi options -idle-timeout 240 -maxClassProcesses 1 and PHP_FCGI_CHILDREN=4 so processes died quite often. [2008-10-09 08:35:41] natit at ctvnet dot dp dot ua HELP CHILDREN OF UKRAINE! Children in need. DONATE EDUCATIONAL MATERIALS TO CHILDREN IN IMPOVERISHED COUNTRIES In some parts of the world, educational materials such as books, paper, pencils, rulers and erasers are scarce and expensive. Donate now to help children in need. PAY PAL na...@ctvnet.dp.ua 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: bgross at mcw dot edu Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0+ Assigned To: dmitry New Comment: I'm not familiar with the inner-workings PHP, so I'm sorry if this is not relevant. I was experiencing a problem with php-cgi processes staying around and filling up my memory. After I added the line "cgi.fix_pathinfo=1" to my php.ini, the problem went away. I'm using PHP FastCGI 5.2.6 with Lighttpd 1.4.19 on Debian 5.0.2 Hope that's helpful Previous Comments: [2009-07-02 03:41:27] porjo38 at yahoo dot com dot au The php 5.3.0 changelog states the following: "Fixed bug #40286 (PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed). (Dmitry)" I've just compiled php 5.3.0 under Centos5.3 with Apache2.2.3 + mod_fcgid2.2-4. The issue is still occuring for me. When I restart Apache, I usually end up with a bunch of php-cgi process with ppid of 1 (init), although it doesn't happen every time. [2009-05-16 03:43:15] scripts at topducks dot com I'm using php5.2.9 mod_fcgid, not using children method. Whenever I restart apache I get orphaned php processes. Without the cron job to check and kill them off they would waste a lot of memory. [2009-01-21 23:34:39] xani666 at gmail dot com In my case that bug was happening on apache + php 5.2.8 + mod_fastcgi + mod_suexec with about ~20 sites (3-4 busy most time of day, other used from time to time) with fastcgi options -idle-timeout 240 -maxClassProcesses 1 and PHP_FCGI_CHILDREN=4 so processes died quite often. [2008-10-09 08:35:41] natit at ctvnet dot dp dot ua HELP CHILDREN OF UKRAINE! Children in need. DONATE EDUCATIONAL MATERIALS TO CHILDREN IN IMPOVERISHED COUNTRIES In some parts of the world, educational materials such as books, paper, pencils, rulers and erasers are scarce and expensive. Donate now to help children in need. PAY PAL na...@ctvnet.dp.ua [2008-05-26 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: porjo38 at yahoo dot com dot au Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0+ Assigned To: dmitry New Comment: The php 5.3.0 changelog states the following: "Fixed bug #40286 (PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed). (Dmitry)" I've just compiled php 5.3.0 under Centos5.3 with Apache2.2.3 + mod_fcgid2.2-4. The issue is still occuring for me. When I restart Apache, I usually end up with a bunch of php-cgi process with ppid of 1 (init), although it doesn't happen every time. Previous Comments: [2009-05-16 03:43:15] scripts at topducks dot com I'm using php5.2.9 mod_fcgid, not using children method. Whenever I restart apache I get orphaned php processes. Without the cron job to check and kill them off they would waste a lot of memory. [2009-01-21 23:34:39] xani666 at gmail dot com In my case that bug was happening on apache + php 5.2.8 + mod_fastcgi + mod_suexec with about ~20 sites (3-4 busy most time of day, other used from time to time) with fastcgi options -idle-timeout 240 -maxClassProcesses 1 and PHP_FCGI_CHILDREN=4 so processes died quite often. [2008-10-09 08:35:41] natit at ctvnet dot dp dot ua HELP CHILDREN OF UKRAINE! Children in need. DONATE EDUCATIONAL MATERIALS TO CHILDREN IN IMPOVERISHED COUNTRIES In some parts of the world, educational materials such as books, paper, pencils, rulers and erasers are scarce and expensive. Donate now to help children in need. PAY PAL na...@ctvnet.dp.ua [2008-05-26 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-05-18 00:39:57] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi We do not support 3rd party stuff, so PLEASE try the unpatched, clean sources provided in above link. 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: scripts at topducks dot com Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0+ Assigned To: dmitry New Comment: I'm using php5.2.9 mod_fcgid, not using children method. Whenever I restart apache I get orphaned php processes. Without the cron job to check and kill them off they would waste a lot of memory. Previous Comments: [2009-01-21 23:34:39] xani666 at gmail dot com In my case that bug was happening on apache + php 5.2.8 + mod_fastcgi + mod_suexec with about ~20 sites (3-4 busy most time of day, other used from time to time) with fastcgi options -idle-timeout 240 -maxClassProcesses 1 and PHP_FCGI_CHILDREN=4 so processes died quite often. [2008-10-09 08:35:41] natit at ctvnet dot dp dot ua HELP CHILDREN OF UKRAINE! Children in need. DONATE EDUCATIONAL MATERIALS TO CHILDREN IN IMPOVERISHED COUNTRIES In some parts of the world, educational materials such as books, paper, pencils, rulers and erasers are scarce and expensive. Donate now to help children in need. PAY PAL na...@ctvnet.dp.ua [2008-05-26 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-05-18 00:39:57] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi We do not support 3rd party stuff, so PLEASE try the unpatched, clean sources provided in above link. [2008-05-06 21:35:25] gabriel at oxeva dot fr Bug reopened as requested by jakobunt at gmail dot com It is indeed the same bug as the one I described: my logs were the same as yours when I was using the php forking feature. As far as I remember, the child php processes were dropped by the parent php process (acting as a dispatcher) because apache's fastcgi process manager "Fastcgi PM" sent a SIGKILL signal to it (the only PID the fastcgi PM is aware of because it spawned it). This signal is normally only sent if the process do not exit a few seconds after being sent a SIGTERM signal. The problem is not the parent being killed, but the children waiting on their own loop infinitely. I guess this bug is in the fastcgi accept loop, which leaves the php children stalled waiting on a FD without any process attached to the other side. 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: xani666 at gmail dot com Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0+ Assigned To: dmitry New Comment: In my case that bug was happening on apache + php 5.2.8 + mod_fastcgi + mod_suexec with about ~20 sites (3-4 busy most time of day, other used from time to time) with fastcgi options -idle-timeout 240 -maxClassProcesses 1 and PHP_FCGI_CHILDREN=4 so processes died quite often. Previous Comments: [2008-10-09 08:35:41] natit at ctvnet dot dp dot ua HELP CHILDREN OF UKRAINE! Children in need. DONATE EDUCATIONAL MATERIALS TO CHILDREN IN IMPOVERISHED COUNTRIES In some parts of the world, educational materials such as books, paper, pencils, rulers and erasers are scarce and expensive. Donate now to help children in need. PAY PAL na...@ctvnet.dp.ua [2008-05-26 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-05-18 00:39:57] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi We do not support 3rd party stuff, so PLEASE try the unpatched, clean sources provided in above link. [2008-05-06 21:35:25] gabriel at oxeva dot fr Bug reopened as requested by jakobunt at gmail dot com It is indeed the same bug as the one I described: my logs were the same as yours when I was using the php forking feature. As far as I remember, the child php processes were dropped by the parent php process (acting as a dispatcher) because apache's fastcgi process manager "Fastcgi PM" sent a SIGKILL signal to it (the only PID the fastcgi PM is aware of because it spawned it). This signal is normally only sent if the process do not exit a few seconds after being sent a SIGTERM signal. The problem is not the parent being killed, but the children waiting on their own loop infinitely. I guess this bug is in the fastcgi accept loop, which leaves the php children stalled waiting on a FD without any process attached to the other side. [2008-05-06 21:08:16] jakobunt at gmail dot com I still experience this on Ubuntu Hardy, PHP 5.2.4-2ubuntu5 with Suhosin-Patch 0.9.6.2 (cgi-fcgi), so this should be reopened. A pstree showing the orphaned processes: http://launchpadlibrarian.net/14265483/phpkiller.log 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: natit at ctvnet dot dp dot ua Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0+ Assigned To: dmitry New Comment: HELP CHILDREN OF UKRAINE! Children in need. DONATE EDUCATIONAL MATERIALS TO CHILDREN IN IMPOVERISHED COUNTRIES In some parts of the world, educational materials such as books, paper, pencils, rulers and erasers are scarce and expensive. Donate now to help children in need. PAY PAL [EMAIL PROTECTED] Previous Comments: [2008-05-26 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-05-18 00:39:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi We do not support 3rd party stuff, so PLEASE try the unpatched, clean sources provided in above link. [2008-05-06 21:35:25] gabriel at oxeva dot fr Bug reopened as requested by jakobunt at gmail dot com It is indeed the same bug as the one I described: my logs were the same as yours when I was using the php forking feature. As far as I remember, the child php processes were dropped by the parent php process (acting as a dispatcher) because apache's fastcgi process manager "Fastcgi PM" sent a SIGKILL signal to it (the only PID the fastcgi PM is aware of because it spawned it). This signal is normally only sent if the process do not exit a few seconds after being sent a SIGTERM signal. The problem is not the parent being killed, but the children waiting on their own loop infinitely. I guess this bug is in the fastcgi accept loop, which leaves the php children stalled waiting on a FD without any process attached to the other side. [2008-05-06 21:08:16] jakobunt at gmail dot com I still experience this on Ubuntu Hardy, PHP 5.2.4-2ubuntu5 with Suhosin-Patch 0.9.6.2 (cgi-fcgi), so this should be reopened. A pstree showing the orphaned processes: http://launchpadlibrarian.net/14265483/phpkiller.log [2007-11-11 22:22:59] jakob dot at at gmx dot net Workaround: Kill those lurking process regularily using a cronjob. This works for me (Ubuntu Dapper, PHP 5.1.2 (cgi-fcgi) (built: Jul 17 2007 17:21:59) ), you probably need pkill -9 . #/bin/bash pkill -f -x /usr/lib/cgi-bin/php -P 1 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286 Comment by: jakobunt at gmail dot com Reported By: gabriel at oxeva dot fr Status: No Feedback Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.0 Assigned To: dmitry New Comment: I still experience this on Ubuntu Hardy, PHP 5.2.4-2ubuntu5 with Suhosin-Patch 0.9.6.2 (cgi-fcgi), so this should be reopened. A pstree showing the orphaned processes: http://launchpadlibrarian.net/14265483/phpkiller.log Previous Comments: [2007-11-11 22:22:59] jakob dot at at gmx dot net Workaround: Kill those lurking process regularily using a cronjob. This works for me (Ubuntu Dapper, PHP 5.1.2 (cgi-fcgi) (built: Jul 17 2007 17:21:59) ), you probably need pkill -9 . #/bin/bash pkill -f -x /usr/lib/cgi-bin/php -P 1 [2007-09-27 03:20:24] atomo64 at gmail dot com [EMAIL PROTECTED]: The problem is that this bug affects Debian's PHP5 package of etch[1] and in order to fix it the right patch is required. We can't simply 'update' the source package. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431799 [2007-09-14 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-09-06 11:16:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-08-22 14:44:48] gabriel at oxeva dot fr Comment from [EMAIL PROTECTED] : I don't believe that this patch could correct blocking I/O. What this patch does is just remove one extra memory pointer which was not needed. Correct fix would be to use O_NONBLOCK when opening file descriptor and then test for EAGAIN. Or use select(2) before reading from descriptor in safe_read() function to test if data is available for reading. I could be wrong, but it just doesn't seems to be fix for this problem. 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 http://bugs.php.net/40286 -- Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286
Comment by: jakob dot at at gmx dot net
Reported By: gabriel at oxeva dot fr
Status: No Feedback
Bug Type: CGI related
Operating System: Linux 2.6
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
Workaround: Kill those lurking process regularily using a cronjob.
This works for me (Ubuntu Dapper, PHP 5.1.2 (cgi-fcgi) (built: Jul 17
2007 17:21:59) ), you probably need pkill -9 .
#/bin/bash
pkill -f -x /usr/lib/cgi-bin/php -P 1
Previous Comments:
[2007-09-27 03:20:24] atomo64 at gmail dot com
[EMAIL PROTECTED]:
The problem is that this bug affects Debian's PHP5 package of etch[1]
and in order to fix it the right patch is required. We can't simply
'update' the source package.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431799
[2007-09-14 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-09-06 11:16:16] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-08-22 14:44:48] gabriel at oxeva dot fr
Comment from [EMAIL PROTECTED] :
I don't believe that this patch could correct blocking I/O.
What this patch does is just remove one extra memory pointer which was
not needed.
Correct fix would be to use O_NONBLOCK when opening file descriptor
and
then test for EAGAIN. Or use select(2) before reading from descriptor
in safe_read() function to test if data is available for reading.
I could be wrong, but it just doesn't seems to be fix for this problem.
[2007-02-16 11:48:12] [EMAIL PROTECTED]
I hope the bug is fixed in CVS HEAD, PHP_5_2 (not in 5.2.1) and PHP_4_4
(not in 4.4.5).
The patch for PHP_5_2 folows:
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi_main.c,v
retrieving revision 1.267.2.15.2.22
diff -u -p -d -r1.267.2.15.2.22 cgi_main.c
--- sapi/cgi/cgi_main.c 15 Feb 2007 12:33:16 - 1.267.2.15.2.22
+++ sapi/cgi/cgi_main.c 16 Feb 2007 11:16:39 -
@@ -355,18 +355,14 @@ static int sapi_cgi_send_headers(sapi_he
static int sapi_cgi_read_post(char *buffer, uint count_bytes
TSRMLS_DC)
{
- uint read_bytes=0, tmp_read_bytes;
-#if PHP_FASTCGI
- char *pos = buffer;
-#endif
+ int read_bytes=0, tmp_read_bytes;
count_bytes = MIN(count_bytes, (uint) SG(request_info).content_length
- SG(read_post_bytes));
while (read_bytes < count_bytes) {
#if PHP_FASTCGI
if (fcgi_is_fastcgi()) {
fcgi_request *request = (fcgi_request*)
SG(server_context);
- tmp_read_bytes = fcgi_read(request, pos, count_bytes -
read_bytes);
- pos += tmp_read_bytes;
+ tmp_read_bytes = fcgi_read(request, buffer + read_bytes,
count_bytes - read_bytes);
} else {
tmp_read_bytes = read(0, buffer + read_bytes,
count_bytes -
read_bytes);
}
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
http://bugs.php.net/40286
--
Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286
Comment by: atomo64 at gmail dot com
Reported By: gabriel at oxeva dot fr
Status: No Feedback
Bug Type: CGI related
Operating System: Linux 2.6
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
[EMAIL PROTECTED]:
The problem is that this bug affects Debian's PHP5 package of etch[1]
and in order to fix it the right patch is required. We can't simply
'update' the source package.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431799
Previous Comments:
[2007-09-14 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-09-06 11:16:16] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-08-22 14:44:48] gabriel at oxeva dot fr
Comment from [EMAIL PROTECTED] :
I don't believe that this patch could correct blocking I/O.
What this patch does is just remove one extra memory pointer which was
not needed.
Correct fix would be to use O_NONBLOCK when opening file descriptor
and
then test for EAGAIN. Or use select(2) before reading from descriptor
in safe_read() function to test if data is available for reading.
I could be wrong, but it just doesn't seems to be fix for this problem.
[2007-02-16 11:48:12] [EMAIL PROTECTED]
I hope the bug is fixed in CVS HEAD, PHP_5_2 (not in 5.2.1) and PHP_4_4
(not in 4.4.5).
The patch for PHP_5_2 folows:
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi_main.c,v
retrieving revision 1.267.2.15.2.22
diff -u -p -d -r1.267.2.15.2.22 cgi_main.c
--- sapi/cgi/cgi_main.c 15 Feb 2007 12:33:16 - 1.267.2.15.2.22
+++ sapi/cgi/cgi_main.c 16 Feb 2007 11:16:39 -
@@ -355,18 +355,14 @@ static int sapi_cgi_send_headers(sapi_he
static int sapi_cgi_read_post(char *buffer, uint count_bytes
TSRMLS_DC)
{
- uint read_bytes=0, tmp_read_bytes;
-#if PHP_FASTCGI
- char *pos = buffer;
-#endif
+ int read_bytes=0, tmp_read_bytes;
count_bytes = MIN(count_bytes, (uint) SG(request_info).content_length
- SG(read_post_bytes));
while (read_bytes < count_bytes) {
#if PHP_FASTCGI
if (fcgi_is_fastcgi()) {
fcgi_request *request = (fcgi_request*)
SG(server_context);
- tmp_read_bytes = fcgi_read(request, pos, count_bytes -
read_bytes);
- pos += tmp_read_bytes;
+ tmp_read_bytes = fcgi_read(request, buffer + read_bytes,
count_bytes - read_bytes);
} else {
tmp_read_bytes = read(0, buffer + read_bytes,
count_bytes -
read_bytes);
}
[2007-01-31 11:56:49] gabriel at oxeva dot fr
And today, I can now confirm that the bugs exists with PHP 5.2.0 too.
Here is the backtrace :
(gdb) bt
#0 0xb7fb2410 in ?? ()
#1 0xbfc06988 in ?? ()
#2 0x0008 in ?? ()
#3 0xbfc069b0 in ?? ()
#4 0x006ee4f3 in __read_nocancel () from /lib/tls/libc.so.6
#5 0x0841b6d4 in fcgi_init_request ()
#6 0x0841b770 in fcgi_read ()
#7 0x0841c546 in fcgi_putenv ()
#8 0x08382d33 in sapi_deactivate ()
#9 0x0837c4f6 in php_request_shutdown ()
#10 0x0841e463 in main ()
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
http://bugs.php.net/40286
--
Edit this bug report at http://bugs.php.net/?id=40286&edit=1
