Bug #72332 [Fbk->NoF]: Enabling opcache on multiple sites results in 500 error

From: Date: Sun, 19 Jun 2016 04:22:29 +0000
Subject: Bug #72332 [Fbk->NoF]: Enabling opcache on multiple sites results in 500 error
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-201725@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72332&edit=1

 ID:               72332
 Updated by:       php-bugs@lists.php.net
 Reported by:      epinci at tiscali dot it
 Summary:          Enabling opcache on multiple sites results in 500
                   error
-Status:           Feedback
+Status:           No Feedback
 Type:             Bug
 Package:          IIS related
 Operating System: WinSrv2012
 PHP Version:      7.0.7
 Private report:   N

 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------
[2016-06-07 23:09:36] 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-07 22:03:11] 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-03 20:43:28] 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?




------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=72332&edit=1


Thread (3 messages)

« previous php.bugs (#201725) next »