Bug 1122803 - enforce size limits on console logs
Summary: enforce size limits on console logs
Keywords:
Status: NEW
Alias: None
Product: Beaker
Classification: Community
Component: general
Version: 0.17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-24 06:39 UTC by Dan Callaghan
Modified: 2018-11-09 23:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Dan Callaghan 2014-07-24 06:39:36 UTC
beaker-watchdog should stop writing any more data to console.log after a configurable size limit has been reached.

We want the limit to be large enough to capture good debugging info from the harness even for large recipes, but small enough that runaway output in an infinite loop won't produce console logs large enough to fill the disk. 10MB would be a good default.

Comment 2 MikeBoswell 2017-01-05 16:46:25 UTC
Dan,  This was sorta addressed w/ log rolling at 100MB.  I don't see the BZ that set that up but am now questioning if we even need to roll them or can we simple delete all logging beyond a particular size.  Eng-ops admins we are called occationally to clear up space on the conservers.  I'm not aware of a time when anyone needed to see 1 of the rolled files so I think we can just dump them.

Comment 3 MikeBoswell 2017-01-05 16:56:27 UTC
I see now the roll is controlled by the conserver.cf config on the conservers but can we still consider enforcing a limit and dumping the rest like this BZ originally requested?

Comment 4 Dan Callaghan 2017-01-06 00:18:00 UTC
Yeah the 100MB rotation done by conserver is really just an emergency measure to save disk space on the conserver -- it doesn't help with the logs which Beaker itself stores (on the LC and then later the archive server). So we do still need this RFE.

As for the conserver rotation, yes you absolutely could configure conserver to drop the old files rather than compressing+rotating them, since as you say nothing is ever going to look at the old rotated files. IIRC we have a cron job which looks for files which have been rotated by conserver and deletes them after a few days, which is a pretty good compromise.


Note You need to log in before you can comment on or make changes to this bug.