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 12:43:22

#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 andysem):

 Replying to [comment:4 Michi Henning <michi.henning@…>]:
 > Eating up all available inodes (on top of the file system being full
 already) is not right.

 Not arguing with that.

 > 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?

 > 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 suspect some sort of stateful error handling is necessary here. If any
 write returns ENOSPC, take note of that fact and remember it. Disable log
 rotation for a while. Occasionally, maybe every 10-60 seconds or so, check
 if there is space available again. If not, rinse and repeat. There is no
 point in continuously bashing away at a file system that is full already…
 >
 > Another check might be to test whether a file is newly-created and
 empty. If so, the first write to the file should immediately unlink it
 again. That way, at least there won't be the endless attempts to create
 more and more files that can't be written to anyway.

 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.

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