Bug#1139273: systemd: wrong execution environment for /etc/rc.local

[Richard Lewis]

Thorsten Glaser <tg at mirbsd.de> 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.