Drupal 7, CiviCRM 4.6, I've just switched a site from being a directory of one domain to it's own new domain. After clearing all caches and resetting the backend configuration, it's able to load the dashboard, but other pages result in what I believe is a race condition - specifically, loading the page seems to trigger the server into calling itself for the same page (i.e. generating an outgoing request to the url being requested). So it ends up in quite the death spiral of resource use.

I know that 4.6 uses outgoing requests to itself to populate the dashboard, but that's not exactly the issue here. I also have noticed that 4.6 uses http requests to itself to identify it's own version, which is also a kind of crazy thing, and I wonder if that's what's creating the death spiral in this case.

Any clues or similar experiences?

  • 1
    Is there any http / https redirection complicating things? – Aidan Dec 21 '17 at 19:38
  • I don't think so. After cutting off the spiral of death by restarting php-fpm, I'm left with about 40 entries in my varnishncsa log that show it was calling itself at the same url, no redirects. There's something in the code that is triggering a request to itself ... I have disabled all the extensions. I guess I could put something in the settings file to do a dump if it sees itself calling itself. ... – Alan Dixon Dec 21 '17 at 19:56
  • OOh, when I try that, it still goes into a spiral of death! – Alan Dixon Dec 21 '17 at 20:20
  • I also tried to intercept before the request goes out with some logic in Utils/System.php which is one place outgoing requests are built, but apparently that's not where this one is coming from. FWIW, there's no referrer and no user agent in the request either. – Alan Dixon Dec 21 '17 at 21:22

Not really a CiviCRM issue, but in case anyone else has a similar experience.

As Aidan correctly guessed, it was indeed due to an http/https redirect - the one that comes from CiviCRM when you tell it to use https for admin/payment pages. Which is why it was okay on some pages, and why it was spawning new php processes for each one.

The reason this site had the problem was due to my use of a separate ssl termination ("Pound") before it went to apache. When you do this, you have to tell apache how it can know if it's been through the termination (via the use of http headers). I hadn't done that for this site, so it kept redirecting itself to the same page, not aware that it was already https.

I put in a redirect from the http to https site, and added the required apache vhost line:

SetEnvIf X-Forwarded-Proto https HTTPS=on

and the issue has now been resolved.

| improve this answer | |
  • its probably worth noting that this is also important for your Drupal sites and others in the settings.php so that Drupal notes its https as well if your behind an ssl termination or a load balancer – Seamus Lee Dec 22 '17 at 22:49
  • Yes, the problem I experienced is a bad configuration problem that needed to be fixed, though I think Civi could be more forgiving ... – Alan Dixon Jan 2 '18 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.