Corrupt cache file crashed forum

[Sir Osis of Liver]

Never saw this before, 2.0.15 forum went wsod, 403 and 500 errors.  Server finally logged a couple -

Code Select Expand



[22-May-2019 17:30:25 UTC] PHP Parse error:  syntax error, unexpected ''a:288:{s:10:"smfVersion";s:5:' (T_ENCAPSED_AND_WHITESPACE) in /home/lapidary/public_html/group/cache/data_955b16a84c976c016b6e76042f847b6c-SMF-modSettings.php on line 1

[22-May-2019 17:30:28 UTC] PHP Parse error:  syntax error, unexpected ''a:288:{s:10:"smfVersion";s:5:' (T_ENCAPSED_AND_WHITESPACE) in /home/lapidary/public_html/group/cache/data_955b16a84c976c016b6e76042f847b6c-SMF-modSettings.php on line 1



Deleted all cached files, forum up and running.  How can a corrupt cached file crash the forum?

[Shambles]

Happened a few times to me, too.

The cached version of your Modsettings.php script will be fed to the php processor in preference to the Sources version, if it exists. Naturally, if that cached copy becomes corrupt you end up feeding a malformed script to the php processor, hence your server errors.

[Sir Osis of Liver]

Shouldn't be too difficult to add an error handler to catch the error and delete the corrupt file before it crashes the forum.  I've disabled caching to prevent it happening again.

[Arantor]

Happened a few times to me, too.

The cached version of your Modsettings.php script will be fed to the php processor in preference to the Sources version, if it exists. Naturally, if that cached copy becomes corrupt you end up feeding a malformed script to the php processor, hence your server errors.

Not quite. There is some confusion over this as 1.1 had a file called ModSettings.php and 2.0 replaces it with ManageSettings.php and some people think this is where the source of it comes from.

The actuality: the contents of the smf_settings table is loaded into a variable called $modSettings, and this is what is stored in the cache to avoid making a database query per page.

I'm a bit disappointed that, yet again, the solution is 'turn caching off' rather than 'ever spend a moment identifying *why* the cache breaks', though I suspect it's the result of the same thing it was last time, for which a fix was proposed and might even go into 2.1 someday or even 2.0.16 if that ever happens.

Something like this commit, although doing it in Load.php in 2.0 rather than its own class and substituting 'SMF' for 'STORYBB'.

[Sir Osis of Liver]

I'm a bit disappointed that, yet again, the solution is 'turn caching off' rather than 'ever spend a moment identifying *why* the cache breaks'.

That's why I asked the question.  Not knowing the solution, disabling caching eliminates the problem, and nothing's lost if it's not a very active forum (it's not).  Apparently not a common glitch, but it's fatal when it happens, and difficult to diagnose if the server's not logging the error.

[Arantor]

Except that disabling it causes you to lose the evidence of what actually broke. Meaning that it guarantees it can't be investigated, let alone fixed properly.

Also the assertion about writing such an error handler... while technically feasible, to actually do so would take significantly more resources than not caching at all.

[Sir Osis of Liver]

Except that disabling it causes you to lose the evidence of what actually broke. Meaning that it guarantees it can't be investigated, let alone fixed properly.

Well, no, disabling was done after determining the cause.  Server was not logging errors early on, contacted host support (it's on my host), then had to go out.  Got back later last night and couple of errors were posted (they may have tinkered with php error logging).  Now I know the cause, deleted cached files, forum came back online.

Also the assertion about writing such an error handler... while technically feasible, to actually do so would take significantly more resources than not caching at all.

So the solution, if it becomes a real problem, is to disable caching.

[Arantor]

Your half-ass solution, maybe. I prefer to actually find the root cause and fix it so I get the benefits of it without having any of the problems of it.

But I guess we'll just make everything run slower so people never have to spend any time actually getting to the cause of the problem.

[Sir Osis of Liver]

I prefer to actually find the root cause and fix it

Well, why don't you?  That was kind of the purpose of my starting this topic.  Seems to be a known problem, but it's certainly beyond my attention span to try to fix it.

[Arantor]

Because I've already submitted every bug fix I've encountered thus far, and every scenario I've seen, I've committed improvements to it. If it's still happening, that's because a case I hadn't thought of is happening and people keep deleting the cache files before they send me a copy to examine.

Hint: deleting the files is literally destroying the evidence that would help me fix it; don't try to blame me for not fixing a problem when no-one gives me the materials to actually examine it!

[Sir Osis of Liver]

This is all I have.  If I see it again on another forum, I'll save the file.

Code Select Expand



[22-May-2019 17:30:25 UTC] PHP Parse error:  syntax error, unexpected ''a:288:{s:10:"smfVersion";s:5:' (T_ENCAPSED_AND_WHITESPACE) in /home/lapidary/public_html/group/cache/data_955b16a84c976c016b6e76042f847b6c-SMF-modSettings.php on line 1

[22-May-2019 17:30:28 UTC] PHP Parse error:  syntax error, unexpected ''a:288:{s:10:"smfVersion";s:5:' (T_ENCAPSED_AND_WHITESPACE) in /home/lapidary/public_html/group/cache/data_955b16a84c976c016b6e76042f847b6c-SMF-modSettings.php on line 1



[Arantor]

The error doesn't really help much, unfortunately, need to see the actual file to see the problem