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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 05, 2013 at 08:51:39PM +0200, Lennart Poettering wrote:
> 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?
I have now pushed a change that adds UNIT= or USER_UNIT= to most
syntax error messages. This patch mostly follows Oleksii's approach,
but extends it to all syntax parsing functions.

The 'issues' patch can now easily go on top, by hooking into
log_syntax_internal.

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

I still think that 'issues' sounds nicest.

Zbyszek