News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Getting random error messages on my forum

Started by Mikeric, April 26, 2013, 12:22:51 PM

Previous topic - Next topic

Mikeric

I am randomly getting error messages on my forum. If you go back and reload the page they go away and it loads fine. This is what I am getting.

QuoteWarning: require(/nfs/c04/h04/mnt/164532/domains/newenglandmustangs.co/html/cache/data_98dbfa6cb9409166f61c1deaff927320-SMF-modSettings.php) [function.require]: failed to open stream: No such file or directory in /nfs/c04/h04/mnt/164532/domains/newenglandmustangs.co/html/Sources/Load.php on line 2715

Fatal error: require() [function.require]: Failed opening required '/nfs/c04/h04/mnt/164532/domains/newenglandmustangs.co/html/cache/data_98dbfa6cb9409166f61c1deaff927320-SMF-modSettings.php' (include_path='.:/usr/local/php-5.3.15/share/pear') in /nfs/c04/h04/mnt/164532/domains/newenglandmustangs.co/html/Sources/Load.php on line 2715

I have these mods installed.

1.     Ad Managment    3.0.1     
2.   Sitemap    2.2.0   
3.   Google Analytics Code    1.4     
4.   Tapatalk SMF 2.0 RC5/Final Plugin    3.5.0     
5.   Add Facebook Like, Tweet, and Google +1    1.0.3a     
6.   Aeva ~ Auto-Embed Video & Audio    7.2     

Kays

Hi, don't quite know why that's happening since the file is checked for existence before it's required.

In Load.php, that line should be the following:


require($cachedir . '/data_' . $key . '.php');


Change the "require" to "include". That should take care of the errors happening.

But the question is why is this happening. Are your forums very busy?

If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

MrPhil

The SMF cache system frequently breaks. Either from your Admin or your file manager clear out all the data_*.php files in the cache directory. Leave index.php and .htaccess.

Arantor

Here's the bit I don't get. Just before that require statement is a file_exists() check. How can it pass the file_exists() but not exist a statement or so later?

Kays

Cache files do get locked when they are written to. Can they be required when they are locked?

Only thing I can think of. ???

If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

Arantor

No, that won't do it, LOCK_EX will not cause a file-not-found error as given above.

I suppose it could be some kind of weird race condition, but it never happens frequently enough or repeatably enough to diagnose properly.

Vector’s Shadow

Quote from: Arantor on April 26, 2013, 01:18:08 PM
Here's the bit I don't get. Just before that require statement is a file_exists() check. How can it pass the file_exists() but not exist a statement or so later?

Possibly because of this:

Quote from: http://php.net/manual/en/function.file-exists.phpNote: The results of this function are cached. See clearstatcache() for more details.

Arantor

Yes, but the cache life on that is not actually very long.

Vector’s Shadow

For as long as two checks happen for the same file within the lifetime of a single script, I don't see why not. Straightforward to check though. Just clear the cache after, say
// Okay, let's go for it memcached!
and see if that fixes it. If so, look to see which mod tried to access it the first time around.

Easy to undo if it doesn't help.

Arantor

QuoteFor as long as two checks happen for the same file within the lifetime of a single script

But different things are checked each call to cache_get_data for the file cache. It actually has more of the symptoms of a race condition than anything else.

But yeah, it's worth a try I guess. I've never been able to reproduce it myself.

Kays

Quote from: Arantor on April 26, 2013, 01:28:09 PM
No, that won't do it, LOCK_EX will not cause a file-not-found error as given above.

Didn't thinks so. ::)

Quote from: Vector's Shadow on April 26, 2013, 02:17:55 PM
For as long as two checks happen for the same file within the lifetime of a single script, I don't see why not. Straightforward to check though. Just clear the cache after, say
// Okay, let's go for it memcached!
and see if that fixes it. If so, look to see which mod tried to access it the first time around.

Easy to undo if it doesn't help.

clearstatcache() is called  automatically when unlink() is used to delete a file. So that that's probably not the problem

If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

Vector’s Shadow


Arantor

The fact that you can't actually put it in and see if it fixes it. It isn't a consistent and repeatable error. You'd need to put it in and leave it for weeks if not months.

And it might not even repeat in that time, even if you hadn't put that statement in.

Vector’s Shadow

All the better if you never see it again. That's the ultimate goal, is it not?

Otherwise you'd just keep theorizing for months before doing anything. What good does that do?

Arantor

You're missing the point.

You won't know if you fixed it or not.

EDIT: Consider the logic.

An error that occurs once and doesn't happen again. You then make some code changes.

Is the error gone because you made code changes, or because it didn't happen again anyway?

Vector’s Shadow

In such cases I put some status checking code in strategic places and write its output to a log file. No matter when it happens, the abnormal behavior usually gets caught close enough to its source for me to figure out its location. But if the OP could do that, we wouldn't be looking at this thread. So the next best thing is to see if there's a likely candidate for failure, which you've identified already, and to try to neutralize it. How else would you know where to look? By tracing the code?

Arantor

-sigh- You do as you please. I personally don't want to waste my time on such a wild good chase.

Vector’s Shadow

I thought the idea was to help the OP, not you or me.

Arantor

I thought the idea was to collectively share wisdom about the OP's problem. I have already explained why any testing you do on this is largely futile unless you have the situation where the problem recurs regularly in the first place.

Like I said, putting in a piece of code that 'fixes' a problem that wasn't occurring anyway is no proof that you fixed the problem.

Vector’s Shadow

And while I don't understand why you want me keep stating the obvious, if the problem occurs again after putting in the code, you will at least know where NOT to look. And it's doing more than sitting on your hands and discussing.

Advertisement: