Occasional "There has been a problem with the database!" Email notice

[Arantor]

Why not change the email message? No technical changes whatsoever, just a change in the explanation (perhaps a link to [a cleaned up version of] this or another thread, even).

Because as already explained, TWO DIFFERENT CAUSES send the same email. One is serious, one is less serious. Changing the email as suggested would mean for the case where it is serious it will be more likely to be ignored.

It's stored in Settings.php?
Then Settings.php is writable by PHP?

Maybe I'm mixing up what you think is optimal and what is actually in practice.

Yes, you are.

Settings.php in theory should not be writable. In practice it usually is which is why it was previously used as the home of this logging value. It's also the subject of a race condition that can wipe out the contents of it. Which is why I've long suggested it being read only. (But then you can get more emails. Usability vs security is a wonderful thing.)

I'm confused. So SMF won't run well on GoDaddy and other major shared hosts but SMF is still intended to be used with them?

SMF will run on just about anything. It'll run at its best when it isn't fighting with hundreds of other sites on a single server, just like anything else.

Consider a road. You can drive down a road without any problems when it's just you on the road. But when you have lots of other drivers, it causes problems - despite the fact that both the road and the cars are all completely fit for purpose.

PHP changes Settings.php. It can do it. There may be an issue of a race condition, but I can't see a greater security problem given that it is possible to alter it with PHP.
Hackers don't take advantage of the frequency with which you do operations but of the fact that you can do operations. Settings.php is either secure or it is not.

YES I KNOW. Which is why it's read only on my servers which is what I've been trying to say... However there are scenarios where you can have it writable without being vulnerable, if the host is properly configured to use suexec or similar (where only the file owner can write to it) But most of the time that doesn't seem to be the case either.

This is a horrible mess to deal with and frankly I want to change it but there's a limit to what I can really do without making it so much less compatible.

Ok, so actually then SMF has (potential) security issues, with the default settings. (Software isn't perfect.)
Therefore, under the default configuration, there would be no particular problem in itself of having a flat file log for this. Your objection is that it's one step forward and two steps back. Fair enough. (For SMF 2.0 or maybe 2.1 then, it might still be a good idea, not that it's clear what to do later.)

Not so much SMF itself, more the entire way PHP operates on most shared hosts. It just so happens that file edits by way of the package manager greatly exacerbate the situation.

Under the default configuration there would be no particular problem in itself of having a flat file log, except for race conditions, a lack of scalability, another PHP file that's active and therefore able to run code...

Ain't going to happen in 2.0 or 2.1.

So you would suggest securing your server, then temporarily unsecuring it, then running the PHP-based update, then resecuring it?
Yes, that would work. I didn't follow that before. You'd actually need to manually change server settings (outside of PHP/SMF) in order to make changes. That's fine and secure. But I don't know that it's the ideal for widespread software like this given that many users don't do that (and may not want to). It's a major tradeoff-- you certainly have a point.

Yup. And it's a problem that all such software has to deal with, but those that actively have to modify their own files certainly have it worse. Any software that can auto update on a webserver is also prone to such issues (WordPress, looking at you)

And yes, I'm well aware most users don't follow best practice. Fortunately, server hosting is getting *better* than it used to be, as things like suexec are coming along and actually entering deployment but the entire situation is far from ideal.

Would it be a particularly bad idea to change "both" messages, then? "Either X or Y happened. SMF can't diagnose which at this time."

There isn't 'both' messages. That's the point: there is only one message, shown in two situations.

And seriously, telling the user 'Oops, something bad went down but we don't know what' isn't going to inspire confidence.

Right. It's effectively useless, at least for this situation. It's a bad situation without a clear fix, I suppose, at least without major rewrites. The only thing I can see is altering the message (in all cases) to explain what the possibilities are. I'd be satisfied with that, at least as a patch.

Which isn't going to change for reasons given above.

Indeed.
Have you thought about a delay?

There are consequences to that too. Hosts have a habit of killing scripts that run too long or consume too much CPU. Adding a delay counts as consuming CPU.

5 seconds is way too long. Even a second is iffy.