Say I have an application, and it writes (among other things) errors to a log file. It's the first place the user would be asked to go and look if there was a problem. Let's also assume that this is a critical application that cannot be allowed to just crash.
For the sake of argument we'll also say that all exceptions are being logged as well. I'm in the boat that says this is a bad idea, but we'll run with it for the sake of this fictional problem.
How should the application ideally handle the situation where it is completely unable to write to its log? Say due to a lack of disk space, exhausted file handle count, or a permissions/access issue.
Depending on the exact reason of course it may be able to partially resolve itself. If there was no free disk space for example it might be reasonable for it to trash the current log to write out a line saying its out of disk space, at the expense of losing the log contents. Although this is very unhelpful if something external is eating space and would just result in logs being emptied.
It may be prudent for it to log to an internal buffer, so that once the situation is resolved no data is lost - but left too long this'd simply munch on memory.
So what do you think, how should a fault notifying the user of an error be handled? Especially with an eye to headless/unattended applications that'd normally just monitored by looking at their logs.