|
|
|
|
|
by thwarted
894 days ago
|
|
I can't make heads or tails of either of those answers, and they seem to contradict each other. The output capturing is all to the same file descriptors, this is the way resources are inherited on fork (and there's no redirection here). That it works with unbuffer is weird because the subshell and subprocess both end up flushing their output when they exit, so there should be no need to flush before exiting. If the first answer is correct, then the unbuffer works because the process introspection as the source of the output is unified to be the unbuffer process. But why bother introspecting the exact process that originated a write to the output? Did we have a problem with file descriptors being highjacked? And even if we did, losing the output (or not associating it with the parent process) is worse. |
|
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.