F20 System Wide Change: No Default Syslog

Lennart Poettering mzerqung at 0pointer.de
Tue Jul 16 11:43:04 UTC 2013


On Tue, 16.07.13 09:42, Till Maas (opensource at till.name) wrote:

> > journalctl only supports local time specifications when you
> > specify calendar times. Unfortunately there's no nice API to map
> > calendar times that include time zone specifications back to UTC, in
> > particular because the time zone names are not unique...
> > While it will be hard to support arbitrary timezone specs in --since= it
> > should be relatively easy to support UTC in addition to the local
> > timezone. Added this to the TODO list.
> 
> You only need to add or subtract hours and minutes from the local time,
> because ISO 8601 dates contain the UTC offset:
> 
> | $ date --iso-8601=seconds
> | 2013-07-15T22:37:04+0200

Well, we can certainly add support for such numeric timezone specs
(added to the TODO list), but I have my doubts that this is actually
what people want to use in their day-to-day use, given that the numbers
are hard to remember. 

I am pretty sure that most folks would like to specify symbolic timezone
names, but that's hard to do due to lack of APIs for that, and the
non-uniqueness of the names.

> > Note that the journal actually knows a concept called "cursors". The
> > cursors are a way to refer to a specific log line (or the closest
> > available one) in a stable way. by using this you can make a logic like
> > the above work nicely, and even remove any inaccuracy regarding
> > timestamps...
> 
> The manpage only mentions how to specify which cursor to use but not how
> to get the cursor of the last read line.

journalctl -o verbose will give you that (and so will -o json, -o export
and others), but the rest of the output is very low-level then. Maybe we
can add a switch that prints the final cursor as last line if you
specify some switch.

If you use the C API you can easily query the cursor string for any line
you like (see sd_journal_get_cursor(3) for details).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list