Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZenCache Pro + PHP 5.6 FASTCGI causes Internal Server Error #671

Closed
renzms opened this issue Feb 9, 2016 · 16 comments
Closed

ZenCache Pro + PHP 5.6 FASTCGI causes Internal Server Error #671

renzms opened this issue Feb 9, 2016 · 16 comments
Milestone

Comments

@renzms
Copy link

@renzms renzms commented Feb 9, 2016

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

@renzms renzms changed the title ZenCache Pro + PHP 5.6 FASTCGI = Internal Server Error ZenCache Pro + PHP 5.6 FASTCGI causes Internal Server Error Feb 9, 2016
@patdumond
Copy link

@patdumond patdumond commented Feb 10, 2016

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

@jaswrks
Copy link

@jaswrks jaswrks commented Feb 12, 2016

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.

2016-02-12_11-03-12

@jaswrks
Copy link

@jaswrks jaswrks commented Feb 12, 2016

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
Copy link

@patdumond patdumond commented Feb 16, 2016

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
Copy link

@jaswrks jaswrks commented Feb 23, 2016

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
Copy link
Contributor

@raamdev raamdev commented Feb 23, 2016

@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
Copy link

@jaswrks jaswrks commented Feb 23, 2016

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

@raamdev raamdev added this to the Next Release milestone Feb 24, 2016
@raamdev raamdev self-assigned this Feb 24, 2016
@raamdev
Copy link
Contributor

@raamdev raamdev commented Feb 24, 2016

@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
Copy link
Contributor

@raamdev raamdev commented Feb 24, 2016

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
Copy link

@jaswrks jaswrks commented Feb 24, 2016

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
Copy link
Contributor

@raamdev raamdev commented Feb 24, 2016

@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
Copy link
Contributor

@raamdev raamdev commented Feb 24, 2016

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

@jaswrks
Copy link

@jaswrks jaswrks commented Feb 24, 2016

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 added a commit to wpsharks/comet-cache-pro that referenced this issue Feb 24, 2016
@raamdev
Copy link
Contributor

@raamdev raamdev commented Feb 27, 2016

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 raamdev closed this Feb 27, 2016
@raamdev
Copy link
Contributor

@raamdev raamdev commented Feb 27, 2016

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).

@wpsharks wpsharks locked and limited conversation to collaborators Feb 27, 2016
@raamdev raamdev removed their assignment Apr 28, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants