Last night my site went down for no reason I can think of—I have not even logged into the hosting account for a week or two. All my other sites are working (Wordpress), but my SMF forum is down. https://speakingofseth.com
The host's support response was this:
"When the error log was enabled, the below error was displayed.
Parse error: syntax error, unexpected ''a:289:{s:10:"smfVersion";s:5:' (T_ENCAPSED_AND_WHITESPACE) in /myhosting/public_html/speakingofseth/cache/data_79a3d1524e1fd33b144899d52c25434d-SMF-modSettings.php on line 1
It seems that the syntax is wrong. Please have a check."
What do I check? How do I fix this? I can't even find a modSettings.php in the directory.
Thanks.
can you attach that file to your next post? then delete it from your server.
Yes, thank you.
UPDATE: I just went to my site and it's up and running again.
You're up and running right now. No longer have admin access, can't see error log. Sounds more like a server glitch than anything wrong with the forum.
That's odd, the attached file contains smf_settings table data. ???
we are pretty sure it is something to do with SMF causing the issue. we just have not figured out what exactly.
Quote from: Sir Osis of Liver on December 11, 2019, 11:18:13 AM
That's odd, the attached file contains smf_settings table data. ???
that is where the mod_settings are stored as far as I can recall. you do know the purpose of cache right?
I disable caching on most forums, they're not busy enough to benefit from it, and it's caused problems. There is no core modSettings.php file, is it a temp file for cache?
it is a cache only file, you will never find a file by that name directly.
Don't know if it's significant, but there's a single quote in line 1 with no closing quote -
'a:289:{s:10:"smfVersion";s:5:"2.0.9";s:4:"news";s:560:"This is a discussion
that could be part of the issue. I have already flagged this topic for one of our devs to review so it may help resolve the issue.
Thank you both, I'm just glad the forum is working again. I've never had that exact problem before. Would my deleting that cache file have fixed it? A second response from the hosting company shows they didn't do anything on their end to fix anything.
Quote from: Sir Osis of Liver on December 11, 2019, 11:33:57 AM
I disable caching on most forums, they're not busy enough to benefit from it, and it's caused problems.
Should I do that too? My forum is not very busy at all. Is that the setting in Admin/Configuration/Caching?
usually you should leave it enabled. your forum should be slightly faster with caching enabled. if this happens on a regular basis then maybe it would be a good idea to turn it off.
yes deleting the file will always fix this issue, given it is a similar error message with this same file.
Quote from: SethStudent on December 11, 2019, 12:45:23 PM
Is that the setting in Admin/Configuration/Caching?
Yes, set it to 'no caching', then do
Admin -> Forum Maintenance -> Empty the file cache. There are a lot of factors that affect page loads, disabling caching should not have a noticeable effect.
Quote from: Sir Osis of Liver on December 11, 2019, 09:21:31 PM
There are a lot of factors that affect page loads, disabling caching should not have a noticeable effect.
it really depends on the size of the forum and the activity level if disabling cache would have a noticeable effect.
So what sort of ballpark would you use as when to use and not use caching?
For example, my forum stats block currently says:
Total Members: 1512
Total Posts: 63616
Total Topics: 4655
Online Today: 258
Online Ever: 783
Users Online now
Users: 4
Guests: 180
(given that includes 5 google bots) it seems a very high number of guests? What else could those be?.
I have caching set to the default 'Level 1 recommended'
if the cache is not causing you issues, I would use it. if it is causing you issues then we could consider other options.
on my forums which are not very active, I have caching enabled and no issues as a result.
Thank you, SethStudent, for catching one of these in the wild. We've seen this for a while, but have not captured an example before.
Very helpful.
This is a known problem, in both 2.0 & 2.1:
- 2.1: https://github.com/SimpleMachines/SMF2.1/issues/5826
- 2.0: Issue #69
I'm going to move this to the bug board.
In the near term until this is addressed, please follow the advise above & consider disabling cache.
I caught the snark! Glad I could be of help for a change, you guys have been helping me for probably 10 years (I had a different login at the time).
I've had my current forum for 5 years and that's the first time I had that particular problem. I may as well turn off the cache, I can always turn it back on if it turns out to be a problem.
FYI it happened again. Got this browser error when visiting my site:
Parse error: syntax error, unexpected ''a:289:{s:10:"smfVersion";s:5:' (T_ENCAPSED_AND_WHITESPACE) in /home/directoryname/public_html/speakingofseth/cache/data_a68943a349dbb5adac538c25f6bee7c0-SMF-modSettings.php on line 1
Attaching the file here. I deleted it after downloading, site is up and running again. For now I've turned off caching.
I checked out the GH conversation on this fault (https://github.com/SimpleMachines/SMF2.1/issues/5826) but didn't see a resolve, unless it's in the pipeline there?
Anyway, I looked at the cache_put_data function declared in Load.php and can see this block of code:
<?php
$fh = @fopen($cachedir . '/data_' . $key . '.php', 'w');
if ($fh)
{
// Write the file.
set_file_buffer($fh, 0);
flock($fh, LOCK_EX);
$cache_bytes = fwrite($fh, $cache_data);
flock($fh, LOCK_UN);
fclose($fh);
// Check that the cache write was successful; all the data should be written
// If it fails due to low diskspace, remove the cache file
if ($cache_bytes != strlen($cache_data))
@unlink($cachedir . '/data_' . $key . '.php');
}
The attempt to secure an exclusive write lock (flock($fh, LOCK_EX)) isn't tested for success before the fwrite is performed, and in a non-locked scenario could the fwrite be returning the number of bytes it was asked to write as opposed to the number it actually wrote, thereby avoiding the ensuing length check and leading to an incomplete/corrupt cached copy of the modSettings file?
No resolution that I know of. The only proposed change related to this is proposing a filesystem lock.
You're right that the result of the lock should be checked, but fwrite will work fine without a lock.
That code block that you've isolated is a fallback for if file_put_contents is missing, a rarity nowadays.
All writing does use locks. Good. Now the reading must also use locks. Observe my code:
<?php
private function readFile($file)
{
if (($fp = fopen($file, 'rb')) !== false)
{
if (!flock($fp, LOCK_SH | LOCK_NB))
{
fclose($fp);
return false;
}
$string = '';
while (!feof($fp))
$string .= fread($fp, 8192);
flock($fp, LOCK_UN);
fclose($fp);
return $string;
}
return false;
}
private function writeFile($file, $string)
{
if (($fp = fopen($file, 'cb')) !== false)
{
if (!flock($fp, LOCK_EX | LOCK_NB))
{
fclose($fp);
return false;
}
ftruncate($fp, 0);
$bytes = 0;
$pieces = str_split($string, 8192);
foreach ($pieces as $piece)
{
if (($val = fwrite($fp, $piece, 8192)) !== false)
$bytes += $val;
else
return false;
}
fflush($fp);
flock($fp, LOCK_UN);
fclose($fp);
return $bytes;
}
The reader uses a shared lock, meaning that no one else can acquire exclusive lock for writing. Any number of processes can acquire a shared lock.
The cache code in SMF does not bother with shared locks, and instead simply uses include(). 2.1 suppresses any parse errors which may result from partiality written files.
The common denominator in these bug reports that I could verify was a file size cutoff of KB.
Closing - This was addressed in 2.0.18.
Quote from: shawnb61 on February 01, 2021, 05:49:07 PMClosing - This was addressed in 2.0.18.
Apparently not. I'm running 2.0.18 and had this happened last night for the first time. Because this has such a significant effect (site won't run at all) I've disabled caching and emptied the cache. If anyone is interested I can upload the file. Don't see that I can do it here.