[systemd-devel] [PATCH 1/2] Report about syntax error in extended format

[Lennart Poettering]

On Tue, 02.04.13 07:33, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> > +        return log_struct(error ? LOG_ERR : LOG_WARNING,
> > +                          "MESSAGE=[%s:%d]: %s", file, line, buf,
> > +                          "MESSAGE_ID=%s\n", error ? CONF_PARSER_ERROR : CONF_PARSER_WARNING,
> > +                          "FILE=%s\n", file,
> > +                          "LINE=%u\n", line,
> > +                          "ERROR=%s\n", buf,
> > +                          NULL);
> Hi,
> what we really need, is getting a proper SYSTEMD_UNIT tag
> for those messages. Then they'll appear in systemctl output,
> without further work.

Fully agree. We already have log_struct_unit() maybe we should extend on
that and have log_syntax_unit() as a macro that adds in the fields?

> The working assumption in systemd is that the journal is available,
> can can be used. So it storing messages in systemd (patch 2/2) goes against
> current design.

Well, I think Oleksii has a point. It might make sense to attach a set
of "issues" to each unit, that are displayed on all "systemctl status"
outputs, whcih need to be resolved before they go away. i.e. unlike
logging about state changes this "issue" logic would stay around until
you resolved it. It's of course difficult to draw the line here between
logging and these "issues", but their persistent nature and that they
require resolving might be a worthwile distinction from normal logging.

In this sense "issues" would be something like a generalization of
"Syntax errors" that are of this sticky, resolving-required style.

Also, I think these issues are probably something that is never stored
on disk, but simply determined on each daemon-reload again. Which also
makes it very different from logging.

If we do this, I am not entirely sure about the name "issue" though. If
we do this I'd like a good name that expresses that this requires
resolving by the admin, and sufficiently makes clear that this is not
logging but more of a "list of current problems", "todo checklist" or
so... Ideas? Any native speakers?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.