<div dir="ltr"><div>>> We *could* consider disabling logging when the disk is tending</div><div>>> towards full, but I suspect that could make a bad problem worse</div><div>>> by losing any possibility of seeing what has actually been going</div>
<div>>> on.</div><div><br></div><div>>I think that if we manage the first several items here (backing off and</div><div>>log rotate), we shouldn't get into this problem. I'm -1 on attempting</div><div>
>to disable logging on low disk</div><div><br></div><div>IMHO it would be prudent to also handle the case when the disk is full as this could happen due to other processes for whatever reason filling up the disk.</div>
<div>If it does, then it should be handled gracefully and raise an error, rather than making the problem worse or assuming it will never happen.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all">
<div><div dir="ltr"><div>-- </div><div>Best Wishes,</div><div><br></div><div>Darryl Weaver</div><div>EMEA Cloud Sales Engineer,</div><div>Canonical</div><div>Desk: +44 (0)207 630 2400 ext 507516</div><div>Mobile: +44 (0)7720088049</div>
<div>GPG FPR: EA3F 3805 9347 87EC 9CBB 8C1E DADC 82C9 B16B 0403</div></div></div>
<br><br><div class="gmail_quote">On 8 December 2013 21:47, Tim Penhey <span dir="ltr"><<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 07/12/13 05:04, roger peppe wrote:<br>
> I think that there are a few things that could help here,<br>
> most important points first:<br>
><br>
> - We should limit agent restarting in some way (exponential backoff or<br>
> retry limits or both)<br>
<br>
</div>I think this is a key one. If the agent is repeatedly failing, we<br>
should back-off and ask for help :-)<br>
<div class="im"><br>
> - We should rotate log files and compress old ones.<br>
<br>
</div>Yes. We have a pending proposal from Nate that adds in log rotation.<br>
<div class="im"><br>
> - We should have kind of policy for expiring and deleting old log files.<br>
<br>
</div>The standard log rotation kind of handles this. You say things like:<br>
* Max of 100 MB<br>
* gzip all but the first<br>
* keep 5 backups<br>
<br>
This is fairly normal.<br>
<div class="im"><br>
> - We should have some way of garbage collecting the transaction log.<br>
<br>
</div>This is our internal issue, but yes, we should consider this as a fairly<br>
high priority item. As I understand it, our transaction log is<br>
primarily for notifications and transactional-ability. What else do we<br>
use it for? How long is the log useful for?<br>
<br>
I know that full logs are useful for diagnosis, but probably not<br>
worthwhile keeping forever.<br>
<br>
Is it feasible for us to be able to export the transaction log to an<br>
external file, and then truncate the internal log?<br>
<div class="im"><br>
> We *could* consider disabling logging when the disk is tending<br>
> towards full, but I suspect that could make a bad problem worse<br>
> by losing any possibility of seeing what has actually been going<br>
> on.<br>
<br>
</div>I think that if we manage the first several items here (backing off and<br>
log rotate), we shouldn't get into this problem. I'm -1 on attempting<br>
to disable logging on low disk.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Tim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</div></div></blockquote></div><br></div>