Thorsten Glaser <[email protected]> writes: > On Mon, 8 Jun 2026, Ansgar 🙀 wrote: > >>Using sockets to back std{in,out,err} seems pretty common, for example >>the "inetd" superserver does so as do CGI scripts and many other >>things. It would be strange if POSIX was to forbid all of these? > > Hmh, POSIX says applications write messages to it, and that was > what did not work. At that point, I didn’t realise that it was > only writing to /dev/stderr that failed, not writing to fd#2 in > general. > > Even though, that needs to be fixed IMHO.
Is this the issue explained in systemd.exec(5), maybe changing the StandardOutput= setting will help?: If the standard output (or error output, see below) of a unit is connected to the journal or the kernel log buffer, the unit will implicitly gain a dependency of type After= on systemd-journald.socket (also see the "Implicit Dependencies" section above). Also note that in this case stdout (or stderr, see below) will be an AF_UNIX stream socket, and not a pipe or FIFO that can be reopened. This means when executing shell scripts the construct echo "hello" > /dev/stderr for writing text to stderr will not work. To mitigate this use the construct echo "hello" >&2 instead, which is mostly equivalent and avoids this pitfall.
