Re: [Boost-bugs] [Boost C++ Libraries] #11016: Boost file logging misbehaves when file system is full

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11016: Boost file logging misbehaves when file system is full
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-02-12 22:45:39

#11016: Boost file logging misbehaves when file system is full
-------------------------------+---------------------
  Reporter:  michi@…           |      Owner:  andysem
      Type:  Bugs              |     Status:  new
 Milestone:  To Be Determined  |  Component:  log
   Version:  Boost 1.55.0      |   Severity:  Problem
Resolution:                    |   Keywords:
-------------------------------+---------------------

Comment (by Michi Henning <michi.henning@…>):

 Replying to [comment:6 andysem]:

 > > If any attempt to write a file returns ENOSPC, all write activity
 should be abandoned. In addition, I would unlink whichever file incurs
 that error.
 >
 > Not if the file is not empty. You wouldn't like losing written logs,
 would you?

 Well… It's questionable whether the log file is valuable in this case.
 It's a bit like running out of memory: the system is in a state where
 correct functioning of some components is impossible. Seeing that this
 case will, in practice, be rare, unlinking the file would be quite
 acceptable, I believe. Running out of space really is an extreme case, and
 it justifies extreme recovery action, IMO.

 > > I don't think throwing an exception would help, in the sense that no
 code that uses boost::log expects to get an exception from one of the API
 calls. Throwing from a logging library just doesn't make sense. What am I
 supposed to do? Catch the exception and log an error about it having
 happened? ;-)
 >
 > I could suggest multiple sensible reactions to such failure, like
 displaying a notification in GUI or cleaning up archived logs or
 terminating the app. The point is that the library has to indicate the
 problem, and it is the application's prerogative to decide how to react.
 You can suppress all exceptions from the library, if you like.

 I don't think a global suppression would help, at least not in all cases.
 I'm logging from a library. I don't know what the code that links with my
 library does. So, I've been very careful not to mess with the global boost
 log state and use separate loggers and sinks that don't interfere with the
 application, even if it happens to use boost log. I can't just change a
 process-wide setting from within a library. That's just as forbidden as
 changing umask or working directory would be.

 In my opinion, throwing from log methods (at least the ones that create
 log messages) is a big no-no. If a log message can't be written, there is
 typically nothing that the code that does the logging can do. All it would
 achieve is that I would have to clutter the calling code with masses of
 catch handlers. Throwing from the log rotate call might be OK, if it's
 well documented that the method can throw. That's because any
 setup/initialization calls for logging are typically in a section of code
 that might have at least a chance of meaningfully reporting an error. But,
 seeing that the log rotation happens transparently while I'm logging, I
 don't think that would help much.

 Throwing from the BOOST_LOG macros is definitely out, as far as I can see.
 All that would achieve is send most programs to terminate(), quick smart.

 > Note that the library is not timer-driven but rather event-driven (where
 events are represented with log records as they are emitted by the app).
 For this reason time-based solutions have limited sense.

 Timers wouldn't be needed. Just remember the current time if a failure
 occurs. Then, when trying to write, if in the error state, check the
 current time and, if within the ban period, skip the write. Once a write
 works, re-enter the no-error state, to avoid the overhead of checking the
 current time.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/11016#comment:7>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.