go runtime panic of trying to re-add container with rootless pod #2964
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
rootless
Comments
openshift-ci-robot
added
the
kind/bug
|
To be more prices, every command returns similar go panic. The only way to fix it is to find podman process ( |
|
More info: I also tried removing some of resulting stopped containers and it returns a different go panic: The only way to fix it was to run |
|
@giuseppe PTAL - potentially related to rootless userns? |
|
I found an easier way to re-produce. Just run this with Podman 1.3.0-dev: And you will get same go panic with |
|
@Fodoj I think you have something wrong with your environment or podmans. I ran both the origina replicator and the one just above as both root and rootless. all of it worked as expected. I would recommend joining us on IRC to investigate further. |
|
@baude sure, how do I do that? |
|
we are on irc.freenode.net in #podman ... |
|
@giuseppe PTAL. From the stacktraces, it seems like a runtime panic out of Go while libpod is in the C code for joining a user namespace. |
|
I downloaded latst build from here (no idea if that's correct place, but I couldnt find any other compiled version of master branch): https://apps.fedoraproject.org/packages/podman/overview/ and it also throws at me the panic, even though it also shows the result of command, for example: So, bug is not reproducible on 1.2.0, but I can easily reproduce it if I compile master branch myself or if I download the latest rpm from here https://apps.fedoraproject.org/packages/podman/overview/. |
|
1.2 is missing the refactor of rootless user namespaces, so this supports my theory |
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Apr 18, 2019
we were previously closing as many FDs as they were open when we first started Podman in the range (3-MAX-FD). This would cause issues if there were empty intervals, as these FDs are later on used by the Golang runtime. Store exactly what FDs were first open in a fd_set, so that we can close exactly the FDs that were open at startup. Closes: containers#2964 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
I think this is caused by us closing the fds not used by Podman. Looks like the detection for how many fds are open is detecting some files that are later closed and we are in facts closing some fds used by golang. To reproduce you'll need to open some FDs like: PR here: #2967 |
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Apr 18, 2019
we were previously closing as many FDs as they were open when we first started Podman in the range (3-MAX-FD). This would cause issues if there were empty intervals, as these FDs are later on used by the Golang runtime. Store exactly what FDs were first open in a fd_set, so that we can close exactly the FDs that were open at startup. Closes: containers#2964 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Apr 18, 2019
we were previously closing as many FDs as they were open when we first started Podman in the range (3-MAX-FD). This would cause issues if there were empty intervals, as these FDs are later on used by the Golang runtime. Store exactly what FDs were first open in a fd_set, so that we can close exactly the FDs that were open at startup. Closes: containers#2964 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
With latest master branch error looks different: |
|
that is a different issue, caused by slirp4netns. What version of slirp4netns are you using? |
|
@giuseppe after doing complete clean and reboot (and also noticing that there was dangling slirp4netns process on port 8000) (and also disabling and stopping docker daemon) it worked fine. Error message is not that clear though. So yes, different issue and a result of local inconsistent setup.. |
weirdwiz
pushed a commit
to weirdwiz/libpod
that referenced
this issue
Apr 21, 2019
we were previously closing as many FDs as they were open when we first started Podman in the range (3-MAX-FD). This would cause issues if there were empty intervals, as these FDs are later on used by the Golang runtime. Store exactly what FDs were first open in a fd_set, so that we can close exactly the FDs that were open at startup. Closes: containers#2964 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
muayyad-alsadi
pushed a commit
to muayyad-alsadi/libpod
that referenced
this issue
Apr 21, 2019
we were previously closing as many FDs as they were open when we first started Podman in the range (3-MAX-FD). This would cause issues if there were empty intervals, as these FDs are later on used by the Golang runtime. Store exactly what FDs were first open in a fd_set, so that we can close exactly the FDs that were open at startup. Closes: containers#2964 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
/kind bug
Version
Podman 1.3.0-dev
OS
Fedora Workstation 29, Linux linux.fritz.box 5.0.4-200.fc29.x86_64 #1 SMP Mon Mar 25 02:27:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
How to reproduce
Note that probably not all ports are needed or even matter. But I still provide full commands I executed:
Now postgres is running and attached to current session. Then I cancel it with CTRL+C and run the same
podman run -e POSTGRESS_PASWORD ...command again.Result:
The text was updated successfully, but these errors were encountered: