Re: [systemd-devel] Connect /usr/bin/init to docker container's STDOUT/STDIN
Nice tip, thank you!
Nicola
On 02/10/22 09:43, Barry wrote:
On 30 Sep 2022, at 14:30, Nicola Mori wrote:
# Save the long-running PID on file
ps aux | grep "sleep infinity" | head -n 1 | awk '{ print $2 }' >
/container-pipes-pid
echo $! >/container-pipes-pid
See man bash for $! definition.
Barry
Re: [systemd-devel] Connect /usr/bin/init to docker container's STDOUT/STDIN
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 (nicolam...@aol.com) 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
[systemd-devel] Connect /usr/bin/init to docker container's STDOUT/STDIN
Hi, sorry in advance if I'm posting to the wrong list. I need to run systemd inside a docker container and attach it to the container's stdin/stdout. The reason for this weird request is the following: 1) I need to use the container for running Gilab CI jobs 2) the software being tested needs systemd to be up and running inside the container 3) Gitlab CI needs a shell running inside the container and attached to the container's STDIN/STDOUT In principle 2) and 3) conflicts because both systemd and the shell needs to be the ENTRYPOINT of the container: systemd needs to run as PID 1 and the shell needs to be attached to container's STDOUT/STDIN. I have been able to solve the problem by: - using /usr/sbin/init as ENTRYPOINT - enabling a custom unit starting a shell attached to STDOUT/STDIN of PID 1: [Unit] Description=Start bash shell attached to container STDIN/STDOUT [Service] Type=simple PassEnvironment=PATH LD_LIBRARY_PATH ExecStart=/bin/bash -c "exec /bin/bash < /proc/1/fd/0 > /proc/1/fd/1 2>/proc/1/fd/2" ExecStopPost=/usr/bin/systemctl poweroff [Install] WantedBy=multi-user.target - defining the container=docker environment variable This works beautifully in a CentOS 7 container running systemd 219: # ls -l /proc/1/fd total 0 lr-x-- 1 root root 64 Sep 29 17:39 0 -> pipe:[1308703] l-wx-- 1 root root 64 Sep 29 17:39 1 -> pipe:[1308704] l-wx-- 1 root root 64 Sep 29 17:39 2 -> pipe:[1308705] but fails when running a Ubuntu 20.04 container with systemd 245: # ls -l /proc/1/fd total 0 lrwx-- 1 root root 64 Sep 29 17:08 0 -> /dev/null lrwx-- 1 root root 64 Sep 29 17:08 1 -> /dev/null lrwx-- 1 root root 64 Sep 29 17:08 2 -> /dev/null In the latter case the fds of PID 1 are connected to /dev/null, so the shell is immediately terminated and no Gtilab CI job can be run. The same behavior occurs with systemd 219 if I don't set container=docker, but with systemd 245 it happens anyway. It happens anyway also in CentOS 7 when running systemd 234 after updating it as described here: https://copr.fedorainfracloud.org/coprs/jsynacek/systemd-backports-for-centos-7/ 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. Thanks in advance for any help and sorry for the long message, Nicola
