On Thu, 11 Oct 2012 01:48:07 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
These two are much better implemented via explicit time seeks. The
journal APIs support that just fine, journalctl currently
doesn't. However it's trivial to add that based on the lower level
APIs, the only thing that stopped me from doing that so far is that
for that we'd have to come up with a nice way to parse calendar
timestamps, and I want to be careful about that. that said the idea
is to have two command line args to journalctl where you can pass
things such as:
$ journalctl --start-time=2012-10-01
...
$ journalctl --start-time=-5d
...
$ journalctl --start-time=2012-01-01 --end-time=2012-05-02
...
And this would do the right things. Since the journal will coalesce
the current journal and the rotated ones into one this will simply
show you everything that matches.
Sounds great.
Of course the time expressions for this need to be powerful enough
so
that people can trivially express things like "everything from today",
or "everything since two weeks ago" and suchlike.
Yeah, I am reminded (pardon the pun) of the 'remind' program that did
this very well.
> "This thing might have messed up when I last booted...
uptime shows
> 16 days"
For this we already have "journalctl -b" which only shows messages
from the current boot. We'll probably extend that later so that you
can pass "journalctl -b4" or so which would show you the messages
from 4 boots earlier only.
Excellent.
The takeaway here is that rotation is not a feature for finding
things. There are much better ways to find things and we should make
them available, and we can, because the backend allows that.
Right, which is why I was trying to move to use cases over just asking
for time rotation. ;) If these use cases can be solved better ways,
thats just fine with me.
kevin