Op di 29 aug 2023 om 10:13 schreef Lennart Poettering <
lenn...@poettering.net>:
> On Sa, 26.08.23 06:14, Cecil Westerhof (cldwester...@gmail.com) wrote:
>
> Please keep mails like this on the mailing list.
>
Sorry, I am used to that when I am responding to a list, my reply goes to
the list. Gmail sadly works differently. Most I did catch, but not all. :'-(
> > We should not "assume the worst", hence given that the stderr stream
> > > is typically used for all kinds of informational messages we should
> > > not always assume its an error, because quite often its just
> > > informational.
> > >
> >
> > You have a very good point. When tcl opens a process for reading, it is
> an
> > error when there is something to read on stderr, except when you overrule
> > it. But that you can overrule it proves your point.
> >
> > > Hence, we use LOG_INFO if we have no clue simply because that's the
> > > "best assumption".
> > >
> >
> > I agree, but I would suggest a very simple solution.
> > There is SyslogLevel which sets the syslog level for stdout and stderr. I
> > would suggest adding SyslogLevelStderr. SyslogLevel would still set it
> for
> > both except when there is also SyslogLevelStderr.
>
> When journal redirection of both stdout + stderr is enabled for
> systemd services we'll connect a single pipe to both fds, in order to
> guarantee ordering, i.e. ensure that if something is written to
> stdout, and then something to stderr, we'll definitely process it in
> this order too. This however means, that on the receiving side we
> cannot distinguish stdout/stderr anymore, it's all one stream. Hence
> we can only choose between: guarantee correct ordering OR ability to
> distinguish stdout/stderr. We opted for the former, as corrupted
> ordering between stdout/stderr is just too confusing for users.
>
I understand your point. But that could be the default behaviour. At the
moment someone uses SyslogLevelStderr it is a conscious choice to take them
apart.
Also: everything has a timestamp, so there is in my opinion when you choose
to take them apart no big problem.
> > We generally recommend apps to use syslog() or sd-journal APIs to
> > > generate their log messages and specify the log level for each message
> > > explicitly, to avoid any doubts. Many programming language's logging
> > > frameworks natively have support for these.
> >
> > The script I use can be run from the command-line and from a service.
> > Because of that I have to use:
> > logMsg --simple "${message}" >&2
> > and:
> > echo "<3>$(logMsg --simple "${message}")" >&2
> >
> > doable but inconvenient.
> >
> > > Now when I want the things send to stderr I also get the things send to
> > > > stdout.
> > >
> > > I can't parse that.
> > >
> >
> > To get what is send to stderr I had to do:
> > journalctl -p 6 -u aptCacheUsage.service
> >
> > which gave beside a lot of other things the things send to stdout.
> >
> > Now I have two different statements I can do:
> > journalctl -p 3 -u aptCacheUsage.service
> >
> > But it would be nice if I did not need two different statements (and the
> > logic around that) for that.
>
> Still not getting what you are trying to say here.
>
Often I am only interested in what is sent to stderr and do not want what
is sent to stdout. When both have the same log level I can not really
filter on messages sent to stderr. At the moment I want to see the messages
sent to stderr, I will also get the messages sent to stdout because they
have the same error level.
--
Cecil Westerhof
