Running cAdvisor on Podman confuses systemd-detect-virt on host

[riyad]

Issue Description

Running cAdvisor with the default volume mounts confuses the host's virtualization detection, because now the host's Systemd thinks it's being run inside a container. This leads to services failing to restart with errors like "ConditionVirtualization=!container was not met". This is unfortunate, because many of Systemd's own units have this conditions and will fail to restart e.g. after package updates.

This happens, because running cAdvisor using the example command from documentation includes the -v /var/run:/var/run:ro option. This leads to Podman creating /run/.containerenv on the host (despite of the ro flag) while it should only be created inside of the container. The host's Systemd picks up on the presence of /run/.containerenv and thinks it is being run inside a container.

Steps to reproduce the issue

Steps to reproduce the issue

1. Run the adapted command from the documentation

sudo podman run \
  --rm
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/containers:/var/lib/containers:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --name=cadvisor \
  --privileged \
  --device=/dev/kmsg \
  gcr.io/cadvisor/cadvisor:v0.52.1

2. Notice /run/.containerenv being created on the host and despite the read-only flag

Describe the results you received

Host's Systemd thinks it's being run inside a container:

$ systemd-detect-virt
podman

Describe the results you expected

/run/.containerenv should only be visible inside the container.

podman info output

Client:        Podman Engine
Version:       5.4.1
API Version:   5.4.1
Go Version:    go1.24.1
Built:         Thu Mar 20 14:36:49 2025
Build Origin:  Ubuntu
OS/Arch:       linux/amd64

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

No response

Additional information

I'd rather Podman not create the .containerenv file at all, than it to leak to the host.

[baude]

this was supposed to have been fixed -> https://github.com/containers/podman/issues/14577 ... there is even still a regression test. Must be some subtlety I dont see r/n

[giuseppe]

even if we don't create the /run/.containerenv file from Podman, when we use -v /run:/run and then bind mount .containerenv to /run/.containerenv, the OCI runtime still needs to create the missing file before the bind mount can be configured. I don't see any alternative except not creating a /run/.containerenv mount at all.

[Luap99]

Well the idea is that we never create and bind mount .containerenv if it is a mount point like done in https://github.com/containers/podman/commit/fcfcd4cdb1b19fe00f6769f33e6704a7f8700d40 which only checks for /run

The reproducer here uses --volume=/var/run:/var/run:ro which commonly is a symlink to /run. I don't think we should make that assumption in podman though. I would just say the fix here is to simply not specify /var/run but rather just /run.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[Luap99]

As there was no further comment I close this, I recommend you mount /run:/run:ro instead then.