Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman-remote: incorrect exit status of 'run --rm' #3808

Closed
edsantiago opened this issue Aug 13, 2019 · 5 comments
Closed

podman-remote: incorrect exit status of 'run --rm' #3808

edsantiago opened this issue Aug 13, 2019 · 5 comments
Assignees
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue

Comments

@edsantiago
Copy link
Member

Like #3795 but with podman-remote instead. Unclear if this is a regression because we've never tested it.

$ podman-remote run --rm alpine /bin/false
$ echo $?
0    <----- expected 1

Also:

window1# podman-remote run --name foo alpine sleep 30

window2# podman-remote rm -f foo   [will take 10 seconds]

window1# echo $?          # after waiting those 10 seconds for prompt to return
0      <------ expected 137, because the container was terminated
edsantiago added a commit to edsantiago/libpod that referenced this issue Aug 14, 2019
...and on a container killed by 'podman rm -f'. See containers#3795

Disable when testing podman-remote; see containers#3808

Signed-off-by: Ed Santiago <[email protected]>
@rhatdan
Copy link
Member

rhatdan commented Aug 19, 2019

This works if you do a podman exec, but not run. We must have the checks for this turned off for remote containers.

@github-actions
Copy link

github-actions bot commented Nov 1, 2019

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

@rhatdan
Copy link
Member

rhatdan commented Nov 1, 2019

We want this fixed, I don't know if it is still a bug. I think it is depending on how you setup podman-remote.

@edsantiago
Copy link
Member Author

I think this is fixed, or at least partly so:

$ ./bin/podman-remote run --rm alpine /bin/false
$ echo $?
1       ! yay

$ ./bin/podman-remote run --rm alpine sh -c 'exit 4'
$ echo $?
4       ! yay

However, there's a new weirdness going on, and I think this may be related to some CI failures we were discussing last month: podman-remote rm -f is returning immediately, even before the container exits:

[10:07:52]$ ./bin/podman-remote run --name foo alpine sleep 30 &
[1] 11804
[10:08:09]$ ./bin/podman-remote rm -f foo
257088a67990163317762fdaee2817a9472770e9c22048b59d561901832b86ee
[10:08:10]$
[1]  + exit 137   ./bin/podman-remote run --name foo alpine sleep 30
[10:08:15]$

That is: I background-run a sleep container and immediately try to rm it. The rm command exits immediately, and then, five seconds later, the container exits. The container exit status is correct, I'm just surprised that podman-remote rm doesn't wait for the exit. Weren't we looking into a related problem recently in CI?

Leaving issue open for now because (1) I want to make sure this behavior is intentional, (2) I want to remind myself to reenable the podman-remote exit-status CI checks so this stays fixed, and (3) I'd like opinions on whether I should file this comment as a separate issue.

@edsantiago
Copy link
Member Author

Update: The exit-status bug was fixed in #3934, and CI tests were enabled then for podman-remote. Thanks, Dan.

Closing, but someone please lmk if the above immediate-exit concern deserves an issue.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue
Projects
None yet
Development

No branches or pull requests

3 participants