php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: epinci at tiscali dot it
New email:
PHP Version: OS:

 

 [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

Add a Patch

Pull Requests

Add a Pull Request

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 Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 02:01:29 2024 UTC