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