Thanks for your insights. I have been able to workaround the problem
with a dirty hack:
- use this script as ENTRYPOINT:
# Start a long-running process to keep the container pipes open
sleep infinity < /proc/1/fd/0 > /proc/1/fd/1 2>&1 &
# Save the long-running PID on file
ps aux | grep "sleep infinity" | head -n 1 | awk '{ print $2 }' >
/container-pipes-pid
# Start systemd as PID 1
exec /usr/lib/systemd/systemd
- modify the shell unit as:
ExecStart=/bin/bash -c "echo Attaching to pipes of PID `cat
container-pipes-pid` && exec /bin/bash < /proc/`cat
container-pipes-pid`/fd/0 > /proc/`cat container-pipes-pid`/fd/1
2>/proc/`cat container-pipes-pid`/fd/2"
Not elegant at all but does its job. Unfortunately I cannot migrate to
podman so I will live with this. And thanks again for your warnings
about docker.
Cheers,
Nicola
On 30/09/22 15:16, Lennart Poettering wrote:
On Do, 29.09.22 19:42, Nicola Mori (nicolamori@xxxxxxx) wrote:
So I believe this problem might have been introduced by a systemd version
subsequent to 219 and that hopefully it might be fixed somehow by means of
e.g. proper configuration of the container/environment, but I need some
advice about what to do since I'm clueless.
Docker is explicitly anti-systemd, you'll always having a hard time
making this work.
Note that since a longer time we'll close /dev/console in PID 1
whenever we can, and only open it immediately before printing stuff to
the console, for compatibility with the kernel's SAK feature which
otherwise would kill PID 1 if SAK is hit.
Thus you really need to pass a proper pty into the container as
/dev/console, if you want systemd to run inside it.
We documented our expectations clearly here:
https://systemd.io/CONTAINER_INTERFACE
Pretty much all container managers implement this more or less. Just
Docker does not...
You might be able to replace docker with podman, where supposed all
this just works out of the box.
Lennart
--
Lennart Poettering, Berlin
