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

Package:
systemd
Source:
systemd
Description:
system and service manager
Submitter:
Thorsten Glaser
Date:
2026-06-08 08:29:02 UTC
Severity:
normal
#1139273#5
Date:
2026-06-08 00:27:55 UTC
From:
To:
Attempting to access stderr in /etc/local fails on systemd
but works on other init systems.

Someone on Fedi tells me that is because systemd expects
services to treat fd#2 as a socket.

However, /etc/rc.local is a POSIX shell script, and POSIX
is pretty clear on std{in,out,err}.

Perhaps /lib/systemd/system/rc-local.service and/or
/lib/systemd/system/rc-local.service.d/debian.conf
need to be changed to invoke /etc/rc.local with 2>&1
to fix that? (Assuming it *can* write to stdout.)
#1139273#10
Date:
2026-06-08 00:40:35 UTC
From:
To:
https://mastodon.social/@shaknais/116711663013528767

This needs to be fixed, somehow.
#1139273#15
Date:
2026-06-08 00:48:11 UTC
From:
To:
Dixi quod…

Perhaps like this?

ExecStart=/bin/sh -c '{ /etc/rc.local start 2>&1 >&3 | cat >&2; } 3>&1 | cat'

That is, if that even works (not tested, only the redirections).
#1139273#20
Date:
2026-06-08 06:33:15 UTC
From:
To:
Hi,

Which clause do you refer to?

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?

Ansgar
#1139273#25
Date:
2026-06-08 08:27:56 UTC
From:
To:
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.

bye,
//mirabilos