Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Blocker
-
Resolution: Won't Fix
-
Affects Version/s: 4.1.3
-
Fix Version/s: None
-
Component/s: Core CiviCRM
-
Labels:None
Description
On an AWS-based install, we are seeing intermittent periods where /civicrm links white screen. Sometimes, clearing the CiviCRM cache makes this go away. But we have seen cases where this appears not to be the case (although see below – we are dealing with multiple instances, since we are on AWS).
This does not appear to be:
- A simple config problem with CIVICRM_TEMPLATE_COMPILEDIR. The app normally works, templates_c gets created, and the en_us subdirectory – the only one we ever see – gets populated.
- An obvious permissions problem with templates_c. We've moved templates_c off of a shared NFS directory into a /tmp/USER-NAME/templates_c directory. /tmp is local to each of the autoscaled instances, and we use the process' Unix user name to separate the nginx web user from any scripts that might be running under some user other than nginx.
- Template specific. While we see certain templates having this problem (CRM/common/jquery.files.tpl seems to be the most common case), it's not specific to one template. None of the templates in question are modified; they are the standard copies for the 4.1.3 release.
At this point, I've instrumented Smarty::trigger_error() so that we get a full stack trace every time trigger_error() is called. I have a complete set of stack traces from our last incident when this occurred, which I'll supply to Lobo (it contains sensitive data, so I can't post it here directly).
This is largely making the site unusable, since it happens often enough that people perceive the site as flaky.
Any help you folks can render is very appreciated.