podman.sock: runtime error: index out of range [0] with length 0 about podman HOT 17 CLOSED

I wonder if this could be the problem. I see that some of these groups are empty:

https://github.com/NixOS/nixpkgs/blob/23f69f50f72ae19d7bbc7271abe30d8bc859207f/pkgs/applications/virtualization/podman/hardcode-paths.patch

cc @WxNzEMof

from podman.

Fixed in #22640

from podman.

Do you have any special containers.conf configured? I can see the place where it can panic but it should not happen with a default config.

from podman.

❯ cat /etc/containers/containers.conf
[engine]
init_path = "/nix/store/zgwgcbzq2qz15mvnn67ks3km0amdi7y9-catatonit-0.2.0/bin/catatonit"

[network]
cni_plugin_dirs = ["/nix/store/lz1ll9v7hf6877v5zzqrgvszbqrkv1xj-cni-plugins-1.4.1/bin"]
network_backend = "netavark"

Is this a non-default config?

I can see the place where it can panic

Do you see a reason why it can panic, to handle it with an explanation?

from podman.

I'm seeing this on NixOS using the default podman config.

	virtualisation.podman = {
		enable = true;
		dockerSocket.enable = true;
	};

% tree /etc/containers
/etc/containers
├── containers.conf -> /etc/static/containers/containers.conf
├── networks
├── policy.json -> /etc/static/containers/policy.json
├── registries.conf -> /etc/static/containers/registries.conf
└── storage.conf -> /etc/static/containers/storage.conf

2 directories, 4 files
% cat /etc/containers/containers.conf
[engine]
init_path = "/nix/store/zgwgcbzq2qz15mvnn67ks3km0amdi7y9-catatonit-0.2.0/bin/catatonit"

[network]
cni_plugin_dirs = ["/nix/store/lz1ll9v7hf6877v5zzqrgvszbqrkv1xj-cni-plugins-1.4.1/bin"]
network_backend = "netavark"
% ls -l /etc/containers/networks
total 0
% cat /etc/containers/policy.json
{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports":
        {
            "docker-daemon":
                {
                    "": [{"type":"insecureAcceptAnything"}]
                }
        }
}
% cat /etc/containers/registries.conf
[registries]
[registries.block]
registries = []

[registries.insecure]
registries = []

[registries.search]
registries = ["docker.io", "quay.io"]
% cat /etc/containers/storage.conf
[storage]
driver = "overlay"
graphroot = "/var/lib/containers/storage"
runroot = "/run/containers/storage"

Downgrading to 4.9.3 fixes it. 5.x seems to have trouble.

from podman.

❯ cat /etc/containers/containers.conf
[engine]
init_path = "/nix/store/zgwgcbzq2qz15mvnn67ks3km0amdi7y9-catatonit-0.2.0/bin/catatonit"

[network]
cni_plugin_dirs = ["/nix/store/lz1ll9v7hf6877v5zzqrgvszbqrkv1xj-cni-plugins-1.4.1/bin"]
network_backend = "netavark"

Is this a non-default config?

I can see the place where it can panic

Do you see a reason why it can panic, to handle it with an explanation?

The default config is no config at all but this won't likely work in the weird nix world. Anyhow non of the keys there should pose any issues so this should not be super relevant AFAIK. Are there nay configs in the user home dir, or /usr/share/containers?

Also could you run podman --log-level trace info that should show some runtime information.

The panic happens because you seem to have a OCIruntime defined without a path:

Of course podman should never panic and handle this case (here likely just ignore it) but I don't see how this can happen unless someone manually specified a runtimes map in containers.conf

from podman.

i.e. a config file like this reproduces

[engine]
[engine.runtimes]
nonstandard_runtime_name = []

from podman.

Are there nay configs in the user home dir, or /usr/share/containers

I was testing on the system wide socket so it should only be using the global config.

from podman.

The panic happens because you seem to have a OCIruntime defined without a path:

What is the standard path for it? I can modify the config file and try again.

I have no user-specific config in ~/.local/share/containers/, only storage related.
I get the same errors regardless of system wide, user wide socket:

❯ curl --unix-socket /var/run/docker.sock http://localhost/info
{"cause":"runtime error: index out of range [0] with length 0","message":"runtime error: index out of range [0] with length 0","response":500}

❯ curl --unix-socket /var/run/user/1000/podman/podman.sock http://localhost/info
{"cause":"runtime error: index out of range [0] with length 0","message":"runtime error: index out of range [0] with length 0","response":500}

from podman.

The config paths would be /usr/share/containers/containers.conf /etc/containers/containers.conf ~/.config/containers/containers.conf + possible .d directories

I doubt that both of you would have any of this set but still I cannot find a reason in code why a path would be unset unless a invalid config was present. I also cannot see any difference with 4.9/5.0 in that regard.

from podman.

Oh yes this patch breaks it. Instead of commenting out the paths it should delete the map entry there.

from podman.

Oh yes this patch breaks it. Instead of commenting out the paths it should delete the map entry there.

I mean it doesn't really matter I guess, we should fix it in podman no matter what and then it should not make a functional difference fot that path

from podman.

Ok, so for a quick fix it should be possible to just comment out the whole stanzas? Then podman can consider the UX of this in a future release?

from podman.

Not sure I followed all points here. The complete fix involves handling the error in Podman and adding the path in NixOs packages?

from podman.

Is there another workaround besides just downgrading to podman 4.9.3?

from podman.

Well for starters did you report this to nixos that there patch broke this? Maybe get them to revert it or fix to not have runtimes without paths defined as mentioned above.

Or well submit a patch to podman to not make it panic on "invalid" configs which should happen regardless if nix fixes it in
the config or not.

from podman.

NixOS/nixpkgs#310182 fixes the patch that was triggering the issue in NixOS. Do you want to leave this open to handle empty lists more gracefully? Or should this be closed?

from podman.