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 top: read /proc/226420/cmdline: no such process #22619

Open
edsantiago opened this issue May 6, 2024 · 4 comments
Open

podman top: read /proc/226420/cmdline: no such process #22619

edsantiago opened this issue May 6, 2024 · 4 comments
Labels
flakes Flakes from Continuous Integration

Comments

@edsantiago
Copy link
Collaborator

Weird one-off seen in debian rootless:

$ podman [options] container run --name test -d quay.io/libpod/alpine:latest top -d 2
5399b1330f7b2db082d006ee6eb2f1f109f3350bacc8b3e369ba90df8da4476d
$ podman [options] container top test
USER        PID         PPID        %CPU        ELAPSED       TTY         TIME        COMMAND
root        1           0           0.000       1.076338999s  ?           0s          top -d 2 
$ podman [options] container top test groups hgroups
Error: read /proc/226420/cmdline: no such process

I fully expect this one to languish, then get closed in a month or two.

@edsantiago edsantiago added the flakes Flakes from Continuous Integration label May 6, 2024
@Luap99
Copy link
Member

Luap99 commented May 6, 2024

Actually I think this is a real error and if one tries it will be not to hard to build a reproducer for as this reminds me off #22103 (comment) which shows that checking only ENOENT is not enough when we parse /proc as other errors can be returned too.

That however does not explain why we have process in such a state here in the test as we only run top and there should be no processes exiting in the meantime in the pid namespace.

@giuseppe
Copy link
Member

giuseppe commented May 7, 2024

the kernel returns ESRCH if the process terminates between the cmdline file is open and it is read, so it would be good to treat unix.ESRCH as ENOENT all over the psgo codebase, but I don't understand how it could have been terminated between the container test top and the container test top groups hgroups commands, I can't spot anything weird in the logs

@Luap99
Copy link
Member

Luap99 commented May 7, 2024

agreed, me neither my only thought is that top got killed by a signal in the meantime or alternatively that another process entered the cgroup (looks like psgo collects the pids for all processes based on the cgroup) then exited/got killed

If it is the first one the test will still fail as top would return no results

@giuseppe
Copy link
Member

giuseppe commented May 7, 2024

I've opened a PR for psgo: containers/psgo#155

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flakes Flakes from Continuous Integration
Projects
None yet
Development

No branches or pull requests

3 participants