The idea here was to archive them just as other logs as sometimes they
can include helpful information. What do others think, is that
something to keep?
Robin
That's true, but in those cases a crash report is sent (which
includes the contents of both of those files, plus others), and
those files are also left in the
<tmpdir>/post-terminate-<date>-<time>-crash directory (this
directory contains both of those two files, plus others, and is
kept on the system until someone runs "broctl cleanup --all").
Also, those two files are not Bro logs (i.e., not in a Bro log
file format), so I thought it might be confusing to store them
in the same directory (with same file extension) as the Bro logs.
-Daniel
> can include helpful information. What do others think, is that
> something to keep?
Yes, please keep! I have found these two files useful many times. It will be nice to keep a copy of both in the post-terminate directory.
Granted, they are not bro logs (format) but information they contain is still useful and their name makes it easy to understand what to expect in these two files.
Aashish
Yeah, that's the point: there may be useful information in there even
during normal operation (i.e., when there's no crash report).
Robin
Not sure what you mean. During normal log rotation, stdout.log/stderr.log are not archived. They are also
not archived during "broctl stop" (assuming no crashes).
We want them archived only when a crash is detected, right?
We want them archived only when a crash is detected, right?
Crash - certainly yes.
Other times - No strong opinion. Would be nice to, if possible. We archive reporter.log, communication.log - these also don't quite carry processed 'IDS' data. Might as well archive these two.
Aashish
OK, I just reverted the previous commit, and added a comment in
the script to avoid confusion in the future.
-Daniel