php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47412 PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
Submitted: 2009-02-16 20:58 UTC Modified: 2019-08-18 04:22 UTC
Votes:6
Avg. Score:4.7 ± 0.7
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:3 (60.0%)
From: tser at deltacontrols dot com Assigned: cmb (profile)
Status: No Feedback Package: CGI/CLI related
PHP Version: 5.2.9RC2 OS: win32 only - Vista
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2009-02-16 20:58 UTC] tser at deltacontrols dot com
Description:
------------
Using FastCGI with IIS, the PHP_MSHUTDOWN_FUNCTION of any extensions are not being called when the php_cgi.exe process is recycled.

PHP_MINIT_FUNCTION(xxx)
{
	REGISTER_INI_ENTRIES();
}

PHP_MSHUTDOWN_FUNCTION(xxx)
{
	UNREGISTER_INI_ENTRIES();

	return SUCCESS;
}

It happens on our custom extension and any standard extension.
It could be easily duplicatable even by putting a break point on 
PHP_MSHUTDOWN_FUNCTION in php_date.c

Reproduce code:
---------------
<?phpinfo();?>

Expected result:
----------------
PHP_MSHUTDOWN_FUNCTION being called.

Actual result:
--------------
PHP_MSHUTDOWN_FUNCTION not being called.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-02-17 15:40 UTC] johannes@php.net
What do you mean by "recycled"? A new request coming in? MSHUTDOWN is only called when the PHP process terminates. RSHUTDOWN is the one being called after each request at request shutdown.
 [2009-02-17 19:25 UTC] tser at deltacontrols dot com
I mean when php-cgi.exe terminates MSHUTDOWN is not being called. This happen when running in FastCGI mode under IIS.
 [2009-04-21 09:50 UTC] jani@php.net
Are you talking about the parent or childs? (And I can not reproduce this on linux, shutdown for every extension is definately called..)
 [2009-04-21 16:38 UTC] tser at deltacontrols dot com
I don't understand the question about parent and child. It is simply the PHP_MSHUTDOWN_FUNCTION not being called (in FastCGI in IIS).

You cannot duplicate it in linux because it does not happen in linux. The bug never mention linux.

The problem is when using PHP in FastCGI mode using IIS (in Vista, not linux)
 [2009-04-21 17:08 UTC] jani@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2009-04-21 19:30 UTC] tser at deltacontrols dot com
5.2.10 (April 21) has the same problem.
 [2009-12-23 02:15 UTC] liak dot liang at gmail dot com
Have the same problem in PHP5.3.0
 [2009-12-23 02:27 UTC] pajoye@php.net
Will verify this issue once I'm back from vacation.
 [2010-01-04 14:00 UTC] pajoye@php.net
It is called as expected (tested on vista/iis and in the console).

If you still experiece this problem, then please provide a detailed way to reproduce:
- what are you doing exactly in IIS
- values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests (IIS setting)


 [2010-01-04 18:52 UTC] tser at deltacontrols dot com
To answer the question, the values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests ar eboth 10000. But they do not come into play to duplicate this problem. The problem could be duplicated before number of request reach these numbers.

I will try to explain the detail using just the standard extension (php_date).

1. Setup PHP FactCGI in IIS. Everything default.
2. Try to run a test.php with this code     <?phpinfo();?>
3. Attach the debugger to php_cgi.exe and make sure it loaded the debug symbol of php_date.
4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c
5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click "Recycle..." on the right hand pane.
6. Notice that the php_cgi.exe will exit but your breakpoint in php_date.c is not triggered.
 [2010-01-12 01:00 UTC] 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".
 [2010-05-12 02:12 UTC] tser at deltacontrols dot com
More information.

Using the latest FastCGI update on IIS7 (KB980363) which support 
SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being called.

Look into the code in sapi/cgi/fastcgi.c
A thread fcgi_shutdown_thread has been created to trap the "_FCGI_SHUTDOWN_EVENT_" 
event but the code simply set in_shutdown to 1. After that, PHP_MSHUTDOWN_FUNCTION 
in the extension code is still not being called.
 [2010-05-13 20:27 UTC] tser at deltacontrols dot com
I cannot re-open the bug.
There are more info on handling of SignalBeforeTerminateSeconds

Please refer to http://forums.iis.net/t/1167753.aspx
 [2010-05-13 21:03 UTC] pajoye@php.net
-Status: No Feedback +Status: Feedback
 [2010-05-13 21:03 UTC] pajoye@php.net
Please post the relevant information here ( > feedback again).
 [2010-05-13 21:29 UTC] tser at deltacontrols dot com
-Status: Feedback +Status: Open
 [2010-05-13 21:29 UTC] tser at deltacontrols dot com
Using Vista64 IIS7 with the update (KB980363).

1. Setup PHP FactCGI in IIS. Everything default.

2. Open C:\Windows\System32\inetsrv\config\applicationHost.config
Edit the <fastCgi> section and add signalBeforeTerminateSeconds="30"

<fastCgi>
            <application fullPath="C:\Program Files (x86)\PHP\php-cgi.exe" maxInstances="2" idleTimeout="30001" activityTimeout="3000" instanceMaxRequests="10000" signalBeforeTerminateSeconds="30">
                <environmentVariables>
                    <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" />
                    <environmentVariable name="PHPRC" value="C:\Program Files (x86)\PHP\" />
                </environmentVariables>
            </application>
</fastCgi>

3. Create a test.php with <?phpinfo();?>. Browse it.
4. Attach debugger to php-cgi.exe process (with debug symbol).
5. Put a breakpoint in sapi/cgi/fastcgi.c (after WaitForSingleObject)
static DWORD WINAPI fcgi_shutdown_thread(LPVOID arg)
{
	HANDLE shutdown_event = (HANDLE) arg;
	WaitForSingleObject(shutdown_event, INFINITE);
	in_shutdown = 1; <--------------breakpoint here
	return 0;
}
6. Put a break point in ext/date/php_date.c
PHP_MSHUTDOWN_FUNCTION(date)
{
	UNREGISTER_INI_ENTRIES();

	return SUCCESS; <----------------breakpoint here
}
7. Open a command prompt and do a iisreset.

Notice that the breakpoint in fcgi_shutdown_thread will get hit but the PHP_MSHUTDOWN_FUNCTION(date) function is not being called.


Before the IIS updates, FastCGI module always force kill php-cgi.exe, make it impossible for php-cgi.exe to properly call PHP_MSHUTDOWN_FUNCTION for each extension. 
With the new setting signalBeforeTerminateSeconds, "_FCGI_SHUTDOWN_EVENT_" will be triggered to give php-cgi.exe a change to do proper cleanup. There are actually code in fastcgi.c (PHP) to wait for that event. However, it still does not properly call PHP_MSHUTDOWN_FUNCTION for all the loaded extension.
 [2010-05-23 23:59 UTC] felipe@php.net
-Status: Open +Status: Assigned
 [2010-06-08 15:49 UTC] tony2001@php.net
See also bug #51760.
 [2017-10-24 07:31 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: pajoye +Assigned To:
 [2019-08-09 13:45 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2019-08-09 13:45 UTC] cmb@php.net
I cannot reproduce the reported behavior.  If you still experience
this issue, please re-open.
 [2019-08-18 04:22 UTC] php-bugs at lists dot php dot 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 "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 18:01:29 2024 UTC