On Di, 29.08.23 11:20, Cecil Westerhof (cldwester...@gmail.com) 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
