On 7/9/2026 9:01 AM, Daniel P. Berrangé wrote: > 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. >
In this case, maybe we can test first podman --remote, before podman. If it can't connect to podman socket, version returns an error as expected. This way, it *works* on your personal setup, and it's fast for everyone else. Sounds like a good compromise? > With regards, > Daniel
