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

Limited cgroup manager usage pattern (and how to fix it) #3178

Closed
kolyshkin opened this issue Aug 24, 2021 · 0 comments · Fixed by #3216
Closed

Limited cgroup manager usage pattern (and how to fix it) #3178

kolyshkin opened this issue Aug 24, 2021 · 0 comments · Fixed by #3216

Comments

@kolyshkin
Copy link
Contributor

kolyshkin commented Aug 24, 2021

Working on fixing #3132, I tried to use a new instance of cgroup manager (as a part of runc run) to check if cgroup already exists (and get all its PIDs). To my suprise, it did not work for most of cgroup managers, because Exists() (and GetAllPids()) rely on cgroup paths being known, and those paths are only initialized during Apply().

In general, it's impossible to use a new instance of a cgroup manager created without known paths (as it is usually done except for runc exec/restore/delete for anything but Apply()!

This issue can be workarounded in many cases by providing an initialized set of paths to New*Manager, but it is not always possible.

There were attempts to partially solve it before on a case-by-case basis (see e.g. commit 4f8ccc5), but that was spotty/incomplete.

The fix is relatively easy (but lengthy)-- we need to move paths initialization from Apply() to New*Manager. This also requires an ability to return an error from New*Manager, as sometimes the cgroup Name/Parent/Path provided is incorrect and we can't initialize paths.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant