podman.sock: runtime error: index out of range [0] with length 0 #22561
Comments
|
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. |
❯ 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?
Do you see a reason why it can panic, to handle it with an explanation? |
|
I'm seeing this on NixOS using the default podman config. virtualisation.podman = {
enable = true;
dockerSocket.enable = true;
};Downgrading to |
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 The panic happens because you seem to have a OCIruntime defined without a path: podman/pkg/api/handlers/compat/info.go Line 196 in c9644eb 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 |
|
i.e. a config file like this reproduces |
I was testing on the system wide socket so it should only be using the global config. |
What is the standard path for it? I can modify the config file and try again. I have no user-specific config in ❯ 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} |
|
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. |
|
I wonder if this could be the problem. I see that some of these groups are empty: cc @WxNzEMof |
|
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 |
|
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? |
|
Not sure I followed all points here. The complete fix involves handling the error in Podman and adding the path in NixOs packages? |
|
Is there another workaround besides just downgrading to podman 4.9.3? |
|
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 |
Change the approach used to integrate runtimes, in order to: - Better support macOS - Make obscure OCI runtimes optional - Work around a panic due to runtimes having no paths (see containers/podman#22561)
|
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? |
Change the approach used to integrate runtimes, in order to: - Better support macOS - Make obscure OCI runtimes optional - Work around a panic due to runtimes having no paths (see containers/podman#22561)
Change the approach used to integrate runtimes, in order to: - Better support macOS - Make obscure OCI runtimes optional - Work around a panic due to runtimes having no paths (see containers/podman#22561)
Change the approach used to integrate runtimes, in order to: - Better support macOS - Make obscure OCI runtimes optional - Work around a panic due to runtimes having no paths (see containers/podman#22561)
Change the approach used to integrate runtimes, in order to: - Better support macOS - Make obscure OCI runtimes optional - Work around a panic due to runtimes having no paths (see containers/podman#22561)
Change the approach used to integrate runtimes, in order to: - Better support macOS - Make obscure OCI runtimes optional - Work around a panic due to runtimes having no paths (see containers/podman#22561)
|
Fixed in #22640 |
Issue Description
I upgraded my system and suddenly got error messages from some endpoints of the Podman socket.
Since updating all packages on my system, some socket endpoints are failing.
Steps to reproduce the issue
$ curl --unix-socket /var/run/user/1000/podman/podman.sock http://info Not Found $ 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} $ curl --unix-socket /var/run/user/1000/podman/podman.sock http://libpod/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}But
curl --unix-socket /var/run/user/1000/podman/podman.sock http://localhost/versionworks as expected (results bellow)Describe the results you received
The returned payload contains a runtime error message:
The logs I got from the
podman.service:Describe the results you expected
I expected the api to not error out. Instead, to return the information without crashing.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Running on NixOs, unstable nixpkgs.
Additional information
I found this issue when i3status-rs errored out on my Docker stats. It connects to a socket to retrieve the data and before the update all was fine.
The text was updated successfully, but these errors were encountered: