F20 System Wide Change: No Default Syslog

Lennart Poettering mzerqung at 0pointer.de
Mon Jul 15 18:18:34 UTC 2013


On Mon, 15.07.13 20:09, Till Maas (opensource at till.name) wrote:

> On Mon, Jul 15, 2013 at 01:31:44PM +0200, Lennart Poettering wrote:
> > On Mon, 15.07.13 12:44, Jan Synacek (jsynacek at redhat.com) wrote:
> > 
> > > On 07/15/2013 11:22 AM, Frank Murphy wrote:
> 
> > > No, logwatch works only with traditional text-based logs. There is this RFE
> > > filed [1], but that will probably not happen as it would require a total
> > > rewrite. It would make more sense to write a new logwatch-like utility from
> > > scratch, that handles only the journal. It's somewhere on my todo list, but has
> > > quite a low priority:(
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=864872
> > 
> > Such a change should be relatively easy. "journalctl" provides you with
> > an output that is pretty much identical to what /var/log/messages
> > contains. Hence, you can replace this:
> > 
> >         f = fopen("/var/log/messages", "r");
> > 
> > by this:
> >    
> >         f = popen("journalctl", "r");
> > 
> > And everything should just continue to work, the stream you read from
> > that is pretty much identical.
> 
> At least for logcheck this won't work, because needs to get access to
> only the log entries that changed since the last run. For this it uses
> logtail whick keeps track for the inode and line offset on each
> invocation. Therefore it seems like it would somehow like this:
> 
> previous_run = "$(cat last_run.txt)"
> current_run = "$(date --iso-8601=seconds --date '1 second ago' |
> head -c 19 | tr "T" " ")
> $log_data = $("journalctl --since $last_run --until $current_run)
> echo "$current_run" > last_run.txt
> 
> But there seems to be the problem that journalctl does not support
> timezones/UTC time for since/until according to journalctl(1), therefore
> there does not seem to be a safe way to specify since/until that will
> even work when the current local UTC offset changes (daylight saving
> time). Also it is sad that journalctl does not directly accept ISO 8601
> time specifications (I can open a bug if there is a changes it will be
> implemented).

glibc is actually smart enough to determine DST from the specified time
itself (of course, this might guess incorrectly since during the switch
there might be times that happen 'twice'), so this should be a
non-issue. 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.

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...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list