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

regression: podman run: exit status 0 after 'rm --force` #3795

Closed
edsantiago opened this issue Aug 12, 2019 · 12 comments
Closed

regression: podman run: exit status 0 after 'rm --force` #3795

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

Comments

@edsantiago
Copy link
Member

# (podman run --name foo alpine sleep 30;echo $?)&
[1] 13212
# podman rm --force foo
[pause 10 seconds]
57c5063848af9f40b436d224ea2ef5808c5db591b6cd1aa0addb3be7e3eddf34
# 0   <--- this is the exit status. It should be 137

podman-1.5.0-2.fc30.x86_64

@rhatdan
Copy link
Member

rhatdan commented Aug 12, 2019

Why should it be 137? Didn't podman rm --force foo work?

@mheon
Copy link
Member

mheon commented Aug 12, 2019

When trying to debug this, I found that events is acting properly strange.
podman events --since 1h --until 1s on 1.4.4 exits instantly, shows me the events in question. In 1.5.0, it seems to hang.

@edsantiago
Copy link
Member Author

podman rm worked. The exit status pointed to by the arrow is that of the container itself, which was killed, therefore its exit status should be 137. Another way to say this:

In window 1:

# podman run --name foo alpine sleep 30

In window 2:

# podman rm -f foo

Then, after the 10-second wait, go back to window 1:

# echo $?
0

Sorry for not being clear.

@edsantiago
Copy link
Member Author

Side note: podman kill foo and podman stop foo both result in a container exit status of 137, as expected. It's only rm -f that is weird.

@edsantiago
Copy link
Member Author

@mheon I cannot reproduce that behavior. I tried with a running container, without; also with running container and running podman rm -f foo during the 10-second wait. The podman events command in question always dumps a bunch of lines, then exits 0.

@mheon
Copy link
Member

mheon commented Aug 12, 2019

It's journald. We're scanning every single journal entry on the system. It's taking 30 seconds to complete on my desktop.

@mheon
Copy link
Member

mheon commented Aug 12, 2019

@baude We're probably going to need a revert of #3745 - it nuked performance of events on systems with long journals.

@rhatdan
Copy link
Member

rhatdan commented Aug 12, 2019

This seems like something we should fix before releasing to Fedora.

@mheon
Copy link
Member

mheon commented Aug 12, 2019

I think I got the core issue here - problem was that we were testing with file backend and not journald. Might want to look into that later.

The events performance thing is separate, and probably does require a revert.

@edsantiago
Copy link
Member Author

Oh, yuk:

# podman run --rm alpine sh -c /bin/false;echo $?
0    <--- should be 1

Without --rm, works as expected (1). Without sh -c, also works as expected.

This may merit a separate issue but I've got a gut sense that they're related. LMK.

@mheon
Copy link
Member

mheon commented Aug 12, 2019

Same issue. Fix in progress.

@mheon
Copy link
Member

mheon commented Aug 12, 2019

#3797 to fix both issues

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]>
mheon added a commit to mheon/libpod that referenced this issue Aug 27, 2019
We weren't actually storing this, so we'd lose the exit code for
containers run with --rm or force-removed while running if the
journald backend for events was in use.

Fixes containers#3795

Signed-off-by: Matthew Heon <[email protected]>
@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.
Projects
None yet
Development

No branches or pull requests

3 participants