On Thu, Jul 09, 2026 at 08:55:08AM -0700, Pierrick Bouvier wrote: > On 7/9/2026 8:40 AM, Daniel P. Berrangé wrote: > > On Thu, Jul 09, 2026 at 07:48:14AM -0700, Pierrick Bouvier wrote: > >> On 2/10/2026 8:35 AM, Daniel P. Berrangé wrote: > >>> When a developer's environment is already within a podman container it > >>> is not possible to use 'podman' again to create containers. It will > >>> usually result in wierd errors such as: > >>> > >>> Error: fatal error, invalid internal status, unable to create a new > >>> pause process: cannot re-exec process to join the existing user > >>> namespace. Try running "podman system migrate" and if that doesn't work > >>> reboot to recover > >>> > >>> Podman offers the ability to talk to a daemon outside the container, > >>> however, which could be leveraged by QEMU. > >>> > >>> This can be used by invoking "podman --remote", or equivalently the > >>> separate "podman-remote" binary: > >>> > >>> > >>> https://github.com/containers/podman/blob/main/docs/tutorials/remote_client.md > >>> > >>> The current 'podman version' check is insufficient to detect the > >>> inability to launch containers, so it is replaced with the stronger > >>> 'podman info' check. > >>> > >>> Signed-off-by: Daniel P. Berrangé <[email protected]> > >>> --- > >>> tests/docker/docker.py | 10 ++++++---- > >>> 1 file changed, 6 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/tests/docker/docker.py b/tests/docker/docker.py > >>> index ff68c7bf6f..9e18b984f4 100755 > >>> --- a/tests/docker/docker.py > >>> +++ b/tests/docker/docker.py > >>> @@ -76,14 +76,16 @@ def _guess_engine_command(): > >>> commands = [] > >>> > >>> if USE_ENGINE in [EngineEnum.AUTO, EngineEnum.PODMAN]: > >>> - commands += [["podman"]] > >>> + commands += [["podman"], ["podman-remote"], ["podman", > >>> "--remote"]] > >>> if USE_ENGINE in [EngineEnum.AUTO, EngineEnum.DOCKER]: > >>> commands += [["docker"], ["sudo", "-n", "docker"]] > >>> for cmd in commands: > >>> try: > >>> - # docker version will return the client details in stdout > >>> - # but still report a status of 1 if it can't contact the > >>> daemon > >>> - if subprocess.call(cmd + ["version"], > >>> + # 'version' is not sufficient to prove a working binary > >>> + # for podman. 'info' is a stronger check that is more > >>> + # likely to correlate with ability to create containers, > >>> + # and required to detect the need for podman remote > >>> + if subprocess.call(cmd + ["info"], > >>> stdout=DEVNULL, stderr=DEVNULL) == 0: > >>> return cmd > >>> except OSError: > >> > >> Taking a look at why tcg tests are slow to compile, I reached this > >> commit. It seems like that calling 'podman info' is 5 to 10 times slower > >> than calling 'podman version'. > >> Thus, a container run now takes +1s when it was 0.2 before. > >> > >> On my setup, podman (remote) version fails correctly if it can't > >> establish a connection. > >> > >> The commit description briefly says > >> ``` > >> The current 'podman version' check is insufficient to detect the > >> inability to launch containers, so it is replaced with the stronger > >> 'podman info' check. > >> ``` > >> but it's not what I observed. > >> > >> Do you have more information about what is the exact reason we can't use > >> 'podman version' for podman-remote? > > > > My developer env involves toolbox, which is a wrapper around podman: > > > > "podman version" is not an operational check - it is effectively > > nothing more than a variant of command line "help". Just shows > > the binary can print to stdout. > > > > By contrast "docker version" is useful as IIUC it shows you can > > connect to docker daemon, but podman is daemonless so the 'version' > > chck doesn't offer any useful proof. > > > > "podman info" is an operational check that correlates with the > > ability to actually create containers. > > > > ⚙️ [host:fedora-44 ~]$ toolbox enter almalinux-toolbox-9 > > ⚙️ [podman:almalinux-9.8 ~]$ sudo dnf -y install podman > > ⚙️ [podman:almalinux-9.8 ~] podman version > > Client: Podman Engine > > Version: 5.8.2 > > API Version: 5.8.2 > > Go Version: go1.26.3 (Red Hat 1.26.3-1.el9_8) > > Built: Tue Jun 16 23:52:20 2026 > > OS/Arch: linux/amd64 > > > > ⚙️ [podman:almalinux-9.8 ~]$ podman info > > Error: fatal error, invalid internal status, unable to create a new pause > > process: cannot re-exec process to join the existing user namespace. Try > > running "podman system migrate" and if that doesn't work reboot to recover > > > > ⚙️ [podman:almalinux-9.8 ~] $ podman --remote info > > OS: linux/amd64 > > provider: qemu > > version: 5.8.2 > > ..snip... > > > > In this case, isn't the problem is that the environment should not have > podman installed if it can't actually create containers?
podman *can* create containers by using the '--remote' flag, which is what we made work in QEMU. > Considering this, I think it would be better to have a "fast" default, > that only checks version, and leave the rest to the user to make sure > their env is correctly configured (or that they remove podman if that's > not the case). My env is correctly configured so that podman --remote works. Doing onmly a version check will make QEMU not work once more. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
