Settings.php suddenly blank

[MrManager]

It looks like my Settings.php file was blanked tonight, which obviously broke my forums. I definitely didn't do anything that might have caused this, though, since I wasn't even awake at the time. I'm using SMF 1.1.4 with the Dilber MC theme.

Any ideas what might have happened? Is this a known issue? Were my forums hacked?

[karlbenson]

Sometimes it can happen if it was being read/written to.  Usually its not being hacked.

Copy the bak version (so you still have the bak version)

Settings_bak.php

[MrManager]

Yeah, I already fixed it, but if it's a bug it is a pretty big bug that should be corrected soon...

[karlbenson]

I don't believe its a bug with smf.
It just can happen with some hosts.

[MrManager]

Even if it's a known issue with PHP, why isn't there a workaround in SMF? It's not like this is just a small cosmetic problem; the bug breaks the entire forums...

And why does SMF even need to write my setting if I didn't change anything?

[greyknight17]

It could be your host as mentioned above. For some reason, once in a blue moon this file gets corrupted. Like you said, you didn't change anything....so most likely something did on the hosts end then

[karlbenson]

Changing the CHMOD on settings.php to remove the 'write' option will probably do the trick.

But it will prevent you changing database settings etc as it will be read-only.
So if you need to change it, you'd have to restore the write CHMOD options.

[MrManager]

It could be your host as mentioned above. For some reason, once in a blue moon this file gets corrupted. Like you said, you didn't change anything....so most likely something did on the hosts end then

If this was really a problem with the server, it should happen to other files too, shouldn't it? I have been using this server for over a year and this is the first time I have seen anything like this.

Changing the CHMOD on settings.php to remove the 'write' option will probably do the trick.

But it will prevent you changing database settings etc as it will be read-only.
So if you need to change it, you'd have to restore the write CHMOD options.

I will do this for now, but I still don't see why the forums even had to write the file in the first place. And even if they did, what exactly went wrong and why?

[JayBachatero]

Ok let me shed some light in this.  This has been explained plenty of times.  What happens is that sometimes 2 users get an error at the exact same time and when SMF tries to write the error number to Settings.php it ends up whipping out the file.

[Douglas]

Settings.php holds the last error timestamp, and your database configurations (which usually don't change) as well as Maintenance mode (which does change from time to time).  If you have two different processes writing to the same sector at the same time, that file is gonna get toast.  It happens ALL the time with Norton and M$ Access (speaking from personal experience as a DBA)

[metallica48423]

Theres a few situations that can cause this to happen, some are server configuration, others are circumstances beyond SMF's control.

Secondly, not every inherent bug in PHP (assuming this were the case) can be necessarily 'worked around'

Either way, no, it is most certainly not a desirable circumstance.

The most common cause of this happening is when the file is being written to for two seperate things at the same time.  For example, if you saved something that writes Settings.php (basically anything in Server Settings) and at the same time it was trying to write an error code/time (which is stored flatfile in Settings.php when sending database connection error emails), it wouldn't be able to do both operations at once.  This can happen with two simultaneous errors as well.  And i think once i've seen it happen with file ownership problems as well

Another circumstance is if,  for whatever reason, the webserver is able to clear it but unable to write back to it.  This can happen if the server is busy and gives up, for the sake of simplicity (its much more complicated than that, in reality)

I won't deny theres probably some things that can be optimized to minimize the occurence of this but in my experience its not a terribly common issue that occurs.   The best way to prevent it is to give the file read only permissions (i believe this is 444 with chmod) And that will prevent it from being wiped at all.  However your Server Settings section of the Admin CP will not be usable (but this is not used often as it stands anyways) so you can leave it that way until you need to edit that information for whichever reason

[MrManager]

This sounds like it would all be fixed by a simple call to flock()...

And even if that doesn't work, why don't you create a separate file for errors? Why are error numbers being saved in a file called "Settings.php" anyway?

[H]

flock() would slow down your site quite a lot if there were lots of php processes running.

The easiest way to work around this php bug is just to make settings.php read-only