Bug#1055830: systemd in a container fails to set up mount namespacing

[Christian Horn]

Hello,

thank you for commenting.

On Wed, Feb 28, 2024 at 07:02:10PM +0100, Michael Biebl wrote:
> 
> On Sun, 12 Nov 2023 11:15:45 +0100 Christian Horn <chris at fluxcoil.net>
> wrote:
> > Package: systemd
> > Version: 252.17-1~deb12u1
> > Severity: important
> > [..]
> 
> From the provided information it is not obvious that this is actually a
> systemd issue. It could be the kernel or any of the dependencies systemd
> relies on or even redis itself.
> 
> In any case, if you think this is a systemd issue, we would need further
> information how to fix this.

The issue still exists with the latest bookworm packages in the container.
Updating then 'redis' in the container to the trixie version does not 
change the issue, update of package systemd pulls in these packages:
  libsystemd-shared libsystemd0 libudev1 
  libzstd1 systemd systemd-timesyncd
..and afterwards redis can be started.

Just in case it helps someone else, reproducer details:
```
# On a Fedora 39 host with podman installed, as user:
mkdir build-bookworm/
cat >build-bookworm/Containerfile<<EOT
FROM docker.io/library/debian:bookworm
ENV DEBIAN_FRONTEND noninteractive
RUN apt update && apt upgrade -y && apt install -y sudo systemd procps redis
CMD [ "/lib/systemd/systemd" ]
EOT
podman build -t repro build-bookworm/
podman run --name repro -d \
	--security-opt seccomp=unconfined --hostname repro \
	localhost/repro /lib/systemd/systemd
podman exec -it repro bash
# Now in the container
systemctl start redis
> Job for redis-server.service failed because the [..]
> See "systemctl status redis-server.service" and [..]
```

There were no further comments from others on this bug, I guess
it's not widely hit.  I work around it now and do not plan to look
deeper, in Trixie it also does not exist.

Thank you,
Christian