[systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps

Lennart Poettering lennart at poettering.net
Thu Jul 18 09:55:47 PDT 2013

On Thu, 18.07.13 10:45, Thomas Bächler (thomas at archlinux.org) wrote:

> Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
> > So, now we have -o short, -o short-monotonic, and --iso-dates.
> > I'm sure we'll add a relative timestamp mode like the excellent one in
> > dmesg --human output in recent util-linux. So I'd say that it makes
> > sense to deprecate short-monotonic and add a new switch --timestamps,
> > --timestamps=monotonic → old short-monotonic
> > --timestamps=iso-date → what you're proposing
> > --timestamps=...
> > 
> > This makes the whole thing easier to grok, imo. Journalctl already has
> > 1½ page listing of options...
> The output options of journalctl have bugged me for some time now. There
> are many options, but the usefulness of many of those is questionable.
> At the same time, the choice of output modes lacks flexibility - this is
> certainly not the last time that someone will come up with a new way to
> format output and submit a patch for it to journalctl.
> In my opinion, journalctl (and the journal API) should get an output
> option that accepts a printf-like format string. With such a format
> string, we would finally get all the flexibility with a simple and
> well-understood syntax.
> In addition to the standard journal fields, format strings could
> reference non-standard fields using a syntax similar to udev's
> '%env{FOOBAR}'. We could be able limit the length of the output similar
> to what is done in printf. We could have (to get back on topic)
> different format modifiers for different date formats (ISO,
> human-readable, epoch, ...).
> Just my 2 cents.

Note that most of the existing output modes can actually not be replaced
by such a format string. For example the "json" mode will serialize a
variable number of paramters into a single line, which is hard to
express in format strings. So, having the current output modes in place is
certainly going to be necessary always.

That said, I'd be open for a patch that adds support for printing logs
via such a format string, as an alternative to the defined output
modes. As syntax I'd prefer if we could requse the % specifier syntax
for the special fields (we already use % specifiers in the unit files,
so this would just reuse this language here), and @FOOBAR@ for the
journal fields (this syntax is already used by the message catalog
stuff, for the same purpose).

I hope that makes sense?


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list