[twic]

AIUI, what happens is that no logging is ever lost, it is just not associated with the right service. This happens when a child process spawns, writes something, then dies before systemd is able to find the child's PID and map it to a service.

This implies that systemd does not just set up a pipe for each service and read everything from that. Rather, it does something like set up a unix domain socket, and then use SO_PEERCRED to find out who is at the other end for each write, then map that to a service by walking the process hierarchy or something. Maybe it's something less nuts than that, but i am not optimistic.

[thwarted]

Yeah, that's what I gathered too. But if you can't find the output, output that is implicitly associated with a process tree as in this example, it is effectively lost. And even if you could find it, that it's disassociated from the origin reduces the utility of having captured the output at all.

SO_PEERCRED is on a per-socket basis, not per-write basis. From unix(7):

              This read-only socket option returns the credentials of
              the peer process connected to this socket.  The returned
              credentials are those that were in effect at the time of
              the call to connect(2) or socketpair(2).

Child processes that inherit the file descriptor like in the example would not influence the SO_PEERCRED result. So it must be something else. For vague reasons.