Req #80812 [Asn->Fbk]: opcache.cache_id should be PHP_INI_PERDIR
| From: | cmb@php.net | Date: | Mon, 01 Mar 2021 14:14:17 +0000 |
| Subject: | Req #80812 [Asn->Fbk]: opcache.cache_id should be PHP_INI_PERDIR | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-232453@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=80812&edit=1
ID: 80812
Updated by: cmb@php.net
Reported by: aschmidt at anamera dot net
Summary: opcache.cache_id should be PHP_INI_PERDIR
-Status: Assigned
+Status: Feedback
Type: Feature/Change Request
Package: opcache
Operating System: Windows
PHP Version: 7.4.15
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> Yes, the mutex log entry is not helpful at all.
Yes, that should be fixed.
> Can you please clarify if your suggestion is to assign an entire
> unique PHP.ini via environment variable.
That can be an option, but my idea was more like using the
environment variable in php.ini, e.g.
opcache.cache_id=${OPCACHE_ID}
Would that work for you?
Changing to PHP_INI_PERDIR might generally make sense, though, but
it appears that would be the only OPcache setting with that
changeability.
Previous Comments:
------------------------------------------------------------------------
[2021-03-01 13:53:18] aschmidt at anamera dot net
Yes, the mutex log entry is not helpful at all. I've struggled with that message for a long
time, trying to isolate directories by PHP version, trying to add cache_ids, trying to set most
liberal NTFS permissions - but without knowing WHAT the actual problem (herror) is, I'm just
blindly plugging my finger into every hole I can think of, until the flow happens to stop.
>> pool specific environment variables <<
The manual doesn't mention environment variables to control OPcache.
Can you please clarify if your suggestion is to assign an entire unique PHP.ini via environment
variable. I understand that this might be a hypothetical option, but in my opinion a very poor one.
It's not good practice to maintain (keep synched) a potentially large number of (mostly)
identical PHP.ini's, depending on the number of sites. Incremental differences is the whole
purpose of PHP's ".user.ini" file.
That's the reason for me suggesting PHP_INI_PERDIR as the allow the user to specifically
override whatever .ini parameter(s) that are unique for a particular site.
>> if both sites run under the same user account (and both use impersonation or not), that
>> shouldn't cause CreateMutex() to fail. <<
Well, the moment I changed one site back to 7.3 yesterday, the problem vanished. I've been
through too many iterations over the last years to remember every detail, but I'm fairly
certain I had the same Mutex problem before you had added the "cache_id" in 7.4:
At present, it all works because 7.3 runs without a cache_id, and 7.4 runs with a cache_id.
It's only after I switched the first site to 7.4, with both sites now sharing same cache_id,
and the Mutex problem resurfaced.
(PS: Before you ask... I'm forced to keep some of my WordPress Sites running 7.3, because of
open 7.4 problems with the uopz and/or componere components.)
------------------------------------------------------------------------
[2021-03-01 11:54:40] cmb@php.net
> "Fatal Error Cannot create mutex"
Great error message. It should at least contain the error code,
to be able to diagnose the problem.
Anyhow, if both sites run under the same user account (and both
use impersonation or not), that shouldn't cause CreateMutex() to
fail. But still it is likely a good idea not to share the OPcache
instance in your case. I'm not sure that changing
opcache.cache_id to PHP_INI_PERDIR is sensible, but it shouldn't
be necessary for IIS anyway, because you can run the two sites
with different application pools, and you can use pool specific
environment variables to run with different cache_ids.
------------------------------------------------------------------------
[2021-02-28 14:26:50] aschmidt at anamera dot net
Description:
------------
I have a Windows Service (PHP 7.4 CLI), plus two IIS web sites, configured to run under the same
Windows User ID with network privileges, because they need to access a certain network share.
One web site was using PHP 7.3, and one web site PHP 7.4 (because it's a development/staging
site).
In the 7.4 php.ini "cache_id" is set.
When I attempt to run the first web site also under 7.4, then scripts will start failing, due to
"Fatal Error Cannot create mutex". I'm assuming, since both IIS sites (with different
application code versions) now share the same PHP version and UserID, this results in a clash?
If so, would the solution be to allow different/unique "cache_id"s to be configured in the
.user.ini of each IIS site, rather than only being able to configure a common one in the system-wide
php.ini?
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=80812&edit=1