I got this error in my email because CRON ran cron.php and somehow a require_once() failed. I'm not too worried since it happened only once, but if you have an idea why this could happen? Looking at the include function it looked just fine to me.
<b>Fatal error</b>: require_once() [<a href='function.require'>function.require</a>]: Failed opening
required './sites/all/modules/views/includes/view.inc'
(include_path='.:/usr/share/php:/usr/share/pear') in
<b>/usr/clients/www/drupal/sites/all/modules/views/views.module</b> on line <b>512</b><br />
Thank you.
Alexis Wilke
Comments
Comment #1
merlinofchaos commentedHm. Not sure what to do about this. It looks like either the current directory is wrong (which might mean that whatever is running cron.php is misconfigured) or the file is missing. Id on't know if I *can* do anything about this.
Comment #2
mmilano commentedI've been getting these error a lot lately. Not just on cron run, but various normal page loads as well.
The file is definitely not missing and has the correct permissions.
Drupal version 6.1.4
Views: 6.x-2.6
Comment #3
merlinofchaos commentedIf the file is not missing that kind of suggests that something changed the current working directory.
Maybe in views_include() you could do a check against the working directory and if it's not the right directory, throw a debug_backtrace() into the watchdog or error log or something and maybe get an idea of what's changing it?
If that's the case, it's not really a Views problem, it's the fault of whatever is changing the cwd.
Comment #4
AlexisWilke commentedI'm getting those errors too. Quite often... it's hard to reproduce so it's hard to know what to do about it. I guess I could add some code to check the folder just before the require_once() and see if cwd is wrong then.
I had another idea about what could make it fail: an out of memory error. But when I get an oom PHP usually tells me so and not "could not open file."
I'll try adding code to see if I can figure out why it happens.
Thank you for the idea.
Alexis
Comment #5
mdorman commentedI noticed the same problem, on my install. I found it to be a problem with Boost, not sure if you have Boost enabled, but take a look here under the boost settings:
[] Clear all cached views pages associated with a node on insert
WARNING: This can be very slow, all views get run to find out where this node lives.
Unchecking that fixed my error problem, as well as a performance issue. I'm now clearing boost view pages manually with an external cronjob.
Comment #6
carlos8f commentedFixed in boost 1.18, see #652508: Views cache not cleared on insert node