[systemd-devel] Connect /usr/bin/init to docker container's STDOUT/STDIN

[Nicola Mori]

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