Op di 29 aug 2023 om 10:13 schreef Lennart Poettering <lennart@xxxxxxxxxxxxxx>:
On Sa, 26.08.23 06:14, Cecil Westerhof (cldwesterhof@xxxxxxxxx) 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
