ZenCache Pro + PHP 5.6 FASTCGI causes Internal Server Error

[renzms]

Customer reported:

Using ZenCache 160120-RC or ZenCache Pro 160103, would not function with PhP 5.6 FastCGI. However, once FastCGI is turned off, they both started to work properly.

Referencing previous closed issue: #624

---

Referencing Internal Ticket: https://websharks.zendesk.com/agent/tickets/10936

[patdumond]

Reference also: Private Internal Ticket: \Fatal Error On Trying To Reactivate Zen Cache Pro.

[jaswrks]

I tested the latest RC against PHP 5.6 w/ FastCGI and there are no issues. I suspect this is a server-specific problem. So far I have been unable to reproduce it.

[jaswrks]

Debugging PHP 5.6 w/ FastCGI

The difference between running PHP w/ FastCGI and without can mean that your server uses a completely different PHP build. Here is a typical breakdown.

• Without FastCGI: PHP is likely compiled into Apache as a DSO. This comes with a heavier footprint and increased RAM usage. Also, there are likely fewer security restrictions imposed at runtime.

• With FastCGI: PHP is not compiled into Apache (i.e., mod_php not used), and instead PHP runs on a socket of its own, called upon whenever files with the .php extension are processed by Apache. This makes Apache lighter overall, because it doesn't carry PHP around on its back all the time.

  With FastCGI enabled, your server is probably configured to run with a completely different PHP build; i.e., if your hosting company gives you the option of turning this on/off, it likely has two different PHP builds that you can pick from. If one of those is missing important PHP extensions, it could trigger the error described in this issue.

  In order for us to find that error, we need to see the PHP error logs from your server, or you need to investigate those yourself and see what actually causes the "Internal Server Error"; i.e., Internal Server Error with FastCGI enabled means there was a PHP parse error. Looks at the logs to find out what that was exactly.

  PHP log files are typically stored in /var/log/php on your server, but this can differ from one hosting provider to another, and it might even depend on the infrastructure that you use. Ask your hosting company where PHP stores log files when it runs with FastCGI.

  If nothing shows up in the PHP error log, look at your Apache or Nginx error log.

[patdumond]

I have an update from internal private ticket referenced above (https://websharks.zendesk.com/agent/tickets/11121). @raamdev said he thought this was a file-locking issue and asked me to have the user ask his hosting company about their locking mechanism. They found that ZenCache had 2 files in the /tmp directory with 2 different owners, thereby preventing ZenCache for locking or using them. They said this can happen if you change PHP handlers (like from Apache to FastCGI). They deleted the files and now ZenCache is working again.

[jaswrks]

Cool. Thank you for this report Pat! :-)

/tmp directory with 2 different owners

@raamdev So it might help if we use 666 permissions on this file.
https://github.com/websharks/comet-cache-pro/blob/160223.1/src/includes/closures/Shared/CacheLockUtils.php#L45

[raamdev]

Also mentioned here: https://wordpress.org/support/topic/white-screen-of-death-lingers?replies=3

[raamdev]

@jaswsinc I don't think this is related, but I noticed that we're not using the b flag with fopen() here: https://github.com/websharks/comet-cache-pro/blob/160223.1/src/includes/closures/Shared/CacheLockUtils.php#L47

PHP.net says:

For portability, it is strongly recommended that you always use the 'b' flag when opening files with fopen().

Is there any specific reason we're not using that flag here?

[jaswrks]

No, no specific reason. Nothing is written to the file though, so I think it's OK without. Either way though.

[raamdev]

@jaswsinc writes...

So it might help if we use 666 permissions on this file.
https://github.com/websharks/comet-cache-pro/blob/160223.1/src/includes/closures/Shared/CacheLockUtils.php#L45

Are you thinking just a call to chmod() right below that line (i.e., chmod($mutex, 0666))? We probably don't want check for a failure there, since if we can't chmod() we may still be able to obtain a lock, right?.

[raamdev]

if we can't chmod() we may still be able to obtain a lock

I'm thinking of a scenario where safe_mode is enabled:

When safe mode is enabled, PHP checks whether the files or directories you are about to operate on have the same UID (owner) as the script that is being executed. http://php.net/manual/en/function.chmod.php#refsect1-function.chmod-notes

[jaswrks]

Are you thinking just a call to chmod() right below that line (i.e., chmod($mutex, 0666))?

Yes. Actually, I'd put it right after this line:
https://github.com/websharks/comet-cache-pro/blob/160223.1/src/includes/closures/Shared/CacheLockUtils.php#L49

We probably don't want check for a failure there, since if we can't chmod() we may still be able to obtain a lock, right?.

Right. I'd just add a @chmod( to suppress any problems there. It's just there as a way to improve compatibility in some edge cases like this. If it fails, no big deal.

I'm thinking of a scenario where safe_mode is enabled:

That's OK. If we can't write to the temp directory there are bigger problems. The getTempDir() method should already deal with this; i.e., it searches for a writable temp directory before we get there.

[raamdev]

@jaswsinc writes...

Yes. Actually, I'd put it right after this line:
https://github.com/websharks/comet-cache-pro/blob/160223.1/src/includes/closures/Shared/CacheLockUtils.php#L49

Can we chmod() on a file that has been opened with an exclusive lock?

[raamdev]

Oh, WE are the one obtaining the lock, so we can do whatever we want, right? 😄

[jaswrks]

Yep :-) Anyway, it's advisory file locking anyway, so you can do whatever. The filesystem itself doesn't really play any part in this, other than just tracking the locks that are open. It doesn't enforce this.

[raamdev]

Next Release Changelog:

• Enhancement: Improved the way Comet Cache handles file locking in an effort to improve compatibility with various environments. There were reports of issues with PHP FPM/FastCGI and this release attempts to address those. See Issue #671

[raamdev]

Comet Cache v160227 has been released and includes changes from this GitHub Issue. See the v160227 announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#671).