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
> Not if the file is not empty. You wouldn't like losing written logs,
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
> 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
-- 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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC