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
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?
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.
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?
Cache files do get locked when they are written to. Can they be required when they are locked?
Only thing I can think of. ???
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.
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.
Yes, but the cache life on that is not actually very long.
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.
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.
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
It's a start. What does it hurt to try?
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.
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?
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?
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?
-sigh- You do as you please. I personally don't want to waste my time on such a wild good chase.
I thought the idea was to help the OP, not you or me.
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.
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.
You're still missing the point. You could let it run for 3 months and not see the error again. After that time would you proclaim it fixed?
The problem is that in 3 months, you might not see the error again *legitimately*. How long do you let it run for to test it? A month? Three months? Six? A year?
I have been running multiple 2.0 installations on my VPS for some years now and I have *never* seen this error on mine. I'm not denying it happens, but absence of an error is not proof of fixed, not when the error is so intermittent and sporadic.
Fine. Do nothing.
What should I do, though? I can't reproduce the bug myself. I've never seen it myself. For me, doing the change would make zero difference since I cannot prove I have dealt with it!
So, I will say it again. If a user is seeing it regularly and consistently, then yes, it's worth doing to see if it makes a difference. But users who *don't* see it can't use it because there's no way to know if it actually solves the problem.
Of the listed mods, are there any that you don't have?
Not relevant. There have been other cases documented where those mods are not installed (but still not consistently enough to be reproducible)
Clean installs with no mods or new themes, too?
That's just it, from all the reports there is nothing in common between them other than the fact they're all errors in the caching system where a file passes the existence test and fails inclusion a statement or so later.
And it's hard to prove you fixed something when you don't have proof it's even happening to start with.
EDIT: This isn't the first time we've had such a bug. But then when it happened, for those it affected, it affected quite regularly. We could put code in to deal with it and know that sooner or later it *would* strike again. This, we can't do so.
Please tell me this happens only on servers with modsecurity.
It's happened on servers with and without mod_security activated. Any other ideas? Not that mod_security would actually make any difference in this situation given what mod_security does and exactly how and where it operates.
and I'll note... I have been running SMF on one or more sites for 9 years, non-stop and I have never seen this error.
Well, my general thinking right now is that you need to be running 2 instances, and in one of them you need to be on line 2658-ish while in the other just jumping into 2715. If write fails, the file would be removed by one instance and attempted to be read by the other. A rare occasion.*
Edit. *This might not be accurate. I'll check it later again when I have a little more time.
I could well believe that there is a race condition here. I documented one years ago that causes Settings.php to be emptied out (and nothing has been done about it). If a particular file is written/erased in one section of code, and another section checks for that file's existence and a statement or two later (non-atomic) tries to read it, it's certain that sooner or later an erase will slip in between the check and the read. If you've got many, many simultaneous users of a given forum, the odds become rather good that something like this will happen from time to time.
I hadn't made any changes yet, but It seems to have stopped coming up. the site is new and not busy at all. I asked a few members and I am going to keep an eye on it.
Everything OK, still?