PHP :: Bug #72332 :: Enabling opcache on multiple sites results in 500 error

Bug #72332

Enabling opcache on multiple sites results in 500 error

Submitted:

2016-06-03 20:43 UTC

Modified:

2016-07-28 09:26 UTC

Votes:	1
Avg. Score:	3.0 ± 0.0
Reproduced:	0 of 0 (0.0%)

From:

epinci at tiscali dot it

Assigned:

Status:

Not a bug

Package:

IIS related

PHP Version:

7.0.7

OS:

WinSrv2012

Private report:

CVE-ID:

None

View Developer Edit

[2016-06-03 20:43 UTC] epinci at tiscali dot it

Description:
------------
If:
> you are runnin PHP in IIS with Zend Opcode extension enabled
> you have multiple sites whose AppPools are running in the same security context (user)
then:
> the first site that gets called after an apppool recycle works fine
> all others fails with 500 server error.

If you have opcache logging turned on you get: "Fatal Error Cannot create mutex" in the log.
It seems the opcache code shared_alloc_win32.c, function get_mmap_base_file creates and locks a file C:\Windows\Temp\ZendOPcache.MemoryBase@<User.Name>@<fixedGUID> which makes it impossible to use Opcode caching under more than one install of PHP under the same user account.
It also seems that the fixedGuid is fixed in all site's opcache file. Should'nt it be variable? What is the use of adding it to the file name if it is always the same?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2016-06-07 22:03 UTC] ab@php.net

-Status: Open +Status: Feedback

[2016-06-07 22:03 UTC] ab@php.net

Thanks for the report.

The file you mention is unlikely to cause this issue, it only holds the base address. My guess is currently, that different app pools are indeed different identities. When the PHP process gets impersonated, it'll inherit the default security descriptor accordingly, however the mutex name will be the same.

I'm not sure what you mean with 

>> you have multiple sites whose AppPools are running in the same security context (user)

Could you please clarify? Are you talking about this? https://technet.microsoft.com/library/hh831797.aspx#ApplicationPoolIdentity

I never tried this scenario, but if the pool identities are same, there should be no issue. 


Thanks.

[2016-06-07 23:09 UTC] epinci at tiscali dot it

Hey! Thank you for following me up on this!

Yes, the link you mentioned is the right reference for the Application Pool Identity.

If the apppool is set to run on the ApplicationPoolIdentity account then IIS "aliases" each site with this configuration to an "own" account ( IIS APPPOOL\[sitename] ) and this does seems to work for opcode caching.
In all other cases (builtin accounts or local accounts), the account is actually specific and the opcode caching seems to collide.

I hit this because, due to acl'ing requirements, my configuration has multiple sites/apppools running under the NetworkService account: this is an easy way to repro this.

Let me know if this makes sense, ok?

[2016-06-19 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.

[2016-07-25 15:33 UTC] ab@php.net

Related To: Bug #72645

[2016-07-28 09:26 UTC] ab@php.net

-Status: No Feedback +Status: Not a bug

[2016-07-28 09:26 UTC] ab@php.net

Please see the linked ticket.

Thanks.

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Mon Dec 30 14:01:28 2024 UTC