Logging throws an exception in FileChannel

[Michael4Adakom]

Hi there, The FileChannel throws an exception if the file locked for open or readonly

A simplified version of my code is....

    Poco::Logger &logger = Poco::Logger::root();
    logger.setChannel(new Poco::SimpleFileChannel("file-is-read-only.log"));
    logger.setLevel(Poco::Message::PRIO_DEBUG);
    logger.information("this log throws an exception"); //  It fails here

From my point of view, a LoggingFramework should never crashes the application, but for this every log usage must be handled with try catch statements. It is possible different by using the AsyncChannel.

My Poco Version is 1.10.1 on win10

[aleks-f]

What is proposed to fix this? Sure, logging throw is not a nice experience; but, once we catch it inside, then where/how do we indicate what happened?

[Michael4Adakom]

Hi and thanks for our quick response,

Logging is a diagnostic feature and I expect no side effects of it or want code that is hard to read. The crash of the application is a bad side effect, and it's hard to find, 'cause it's depends on the logging configuration like the log target, level and file system. How is exception handled in the AsyncChannel? The app doesn't crash when I put this channel in between: The log fails silently

Poco::Logger &logger = Poco::Logger::root();
logger.setChannel(new Poco::AsyncChannel(new Poco::SimpleFileChannel("file-is-read-only.log")));
logger.setLevel(Poco::Message::PRIO_DEBUG);
logger.information("this log throws an exception"); //  It will not crash

My porpose is to have a transparent behavour with and without AsyncChannel. Is it possible, to raise the exception (only) in the configuration?.

[aleks-f]

My porpose is to have a transparent behavour with and without AsyncChannel.

that was clear from the original post

Is it possible, to raise the exception (only) in the configuration?.

I guess you mean catch the exception during logging hierarchy build? anything is possible, but log files eventually rotate and may become read-only from external cause, and the question still remains: what to do about it? you could redirect output to stderr, but if the process is running in the background, a file on disk is needed, and you have kicked the problem down the road - what to do if that file is read only? no logging, forever?

[Michael4Adakom]

Yes, no logging forever!

For myself, the log fiiles have a really smal business value. A users of the application does not care if a logging file exists or not. Only in a request for support is it usefull. But customers cares when an application crashes. From that point of view, no logging is okay. You are right, on the other side and for an (fictional) webserver, should the server shutdown if the access log can not be written / rotated / etc? I can not give an answer for every case. In the sense of "explicit before implicit!", is it possible to set a property for that?

  pChannel->setProperty("throw exceptions", "never");

[aleks-f]

All that could be carefully done. I, however, have currently no time or need for it. Unless someone else does, if you want to see it in, you'll have to send a well thought out pull request with the changes you are proposing.

While the expectation that logging should not crash the application is reasonable, so is the expectation that people should not be tinkering with the application log files, especially not by setting them read-only.

[intensifi]

I STRONGLY DISAGREE that logging is only diagnostic feature and no side effects should be caused by logging failures in the general sense.

For a command line application, I can maybe understand this expectation.

For a Poco server application, having logging crash the application if an issue such as you describe occurs is a GOOD thing. A few weeks back a customer of ours had a server application based on Poco::Util::ServerApplication crash. It had been working fine for months. The reason was some "bad guys" messed with the syslog configuration to try and cover their tracks. This change caused the server application I mention to crash when it tried to write a standard log entry. This led to an investigation which led to the discovery. For long running server daemons, a completely functioning logging environment with rotation is key. If that subsystem fails, I am fine with the application crashing.

Now all that said, an exit code or console message that indicates the logging system went sideways WOULD be appreciated .

[Michael4Adakom]

Okay, but than has it to be explicit. Because Poco does not crash, when an AsyncChannel wraps the FileChannel. At least the documentation should be more pecisely, in a way like "the call of logger.warning(..) could throw an exeption..."

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 60 days since being marked as stale.