Re: Why are the priorities of stdout and stderr the same

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 29.08.23 11:20, Cecil Westerhof (cldwesterhof@xxxxxxxxx) wrote:

> Also: everything has a timestamp, so there is in my opinion when you choose
> to take them apart no big problem.

For stream connections like those used for stdout/stderr, lines do not
come with timestamps. We add them on the reception side, which is too late.

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

I agree with that usecase, and we have discussed this many times
before, but we couldn#t come up with a nice way to make everything
work: proper ordering and distintion of stdout/stderr.

The closest I cam was using two distinct SOCK_DGRAM sockets
connect()ed to the same target socket (instead of the current approach
of using SOCK_STREAM). This would give us two benefits: for each
deliverd datagram we would get a source socket address reported to us,
and it will tell us which of the two source sockets it was, hence
hence if stdout or stderr. Moreover, we would get a kernel-supplied
kernel timestamp on each datagram if we want. This however has a
fairly big problem too: if programs write too much data into their
stdout/stderr at once they would get EMSGSIZE back, which programs
generally don't expect (i.e. if write()'s size is larger than datagram
max size you get EMSGSIZE). Programs trying to write too much usually
expect blocking behaviour... Thus this approach is not really an
option.

Lennart

--
Lennart Poettering, Berlin