[systemd-devel] RFC: filter and search journalctl
Anne Mulhern
amulhern at redhat.com
Tue Aug 18 06:00:27 PDT 2015
----- Original Message -----
> From: "Anne Mulhern" <amulhern at redhat.com>
> To: systemd-devel at lists.freedesktop.org
> Sent: Monday, August 17, 2015 11:34:10 AM
> Subject: Re: [systemd-devel] RFC: filter and search journalctl
>
>
>
>
>
> ----- Original Message -----
> > From: "Zbigniew Jędrzejewski-Szmek" <zbyszek at in.waw.pl>
> > To: "Anne Mulhern" <amulhern at redhat.com>
> > Cc: systemd-devel at lists.freedesktop.org, "Sebastian Schindler"
> > <sebastian.schindler at travelping.com>
> > Sent: Monday, August 17, 2015 10:45:11 AM
> > Subject: Re: [systemd-devel] RFC: filter and search journalctl
> >
> > On Mon, Aug 17, 2015 at 10:24:22AM -0400, Anne Mulhern wrote:
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Zbigniew Jędrzejewski-Szmek" <zbyszek at in.waw.pl>
> > > > To: "Sebastian Schindler" <sebastian.schindler at travelping.com>
> > > > Cc: systemd-devel at lists.freedesktop.org
> > > > Sent: Saturday, August 8, 2015 3:48:30 PM
> > > > Subject: Re: [systemd-devel] RFC: filter and search journalctl
> > > >
> > > > On Fri, Aug 07, 2015 at 11:53:13AM +0200, Sebastian Schindler wrote:
> > > > > Grep-ing seems to be the only solution to find log entries if you
> > > > > don't
> > > > > fully
> > > > > know what you're looking for. For example: You want to see all
> > > > > entries
> > > > > containing a certain MESSAGE that gets enriched with additional
> > > > > information
> > > > > during the logging process:
> > > > >
> > > > > MESSAGE=host <HOST> has closed connection <CONNECTION_ID>
> > > > This is a bit contentious, but at least I would like to see some
> > > > grep functionality implemented directly in journalctl.
> > > >
> > >
> > > I am late to the party, but I think it is obvious that the "right" way
> > > for
> > > this
> > > to be achieved, in a perfect world, is that this log entry be accompanied
> > > by a MESSAGE_ID, and HOST and CONNECTION_ID keys, and a catalog entry
> > > that
> > > combined
> > > with the keys, generates the above message so that grepping is entirely
> > > unnecessary.
> > >
> > > It is true that this perfect world is not just around the corner, or
> > > anything like that,
> > > but it is technically possible.
> > >
> > > I agree that grepping would be handy for me, right now, for just the
> > > reasons stated
> > > in the original message.
> > >
> > > I wonder if it would be reasonable for journalctl to supply the
> > > (additional) fields that are
> > > guaranteed to be associated with a MESSAGE_ID
> > And what what happen when the entry is "malformed", i.e. missing some
> > fields?
> > Would journald reject the message? I don't think this would be useful to
> > anyone at all. Instead the readers of the message should gracefully adapt
> > to missing fields.
> >
>
> I think it would be wrong for journald to reject a message that does not
> supply
> all the declared fields. It would also be wrong for journalctl to crash when
> given the
> --catalog flag if the fields are missing. I don't know what it does right
> now, because it is not that easy a situation to engineer, AFAICT. I guess the
> best thing would be to supply a special catalog message indicating that an
> error had occurred when trying to construct a catalog message. Something
> that indicated the fields that were missing that caused the error would be
> nice.
> Just so long as that didn't turn into an infinite loop, somehow. If somebody
> knows what journalctl does do in this situation, please pass that information
> along.
Re-reading the docs, I realize that the information is right there in plain sight.
If the value is not defined, the variable name, minus the @ signs, is displayed.
Nice and simple.
But now, I wonder what happens for fields like _UDEV_DEVLINK, which can be set
0, 1, or many times. If unset, the variable name minus the @ signs is displayed.
If set once, the value is substituted. If set twice?
<-- SNIP -->
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
- mulhern
More information about the systemd-devel
mailing list