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.

Sign up for GitHub

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

Jump to bottom

restore --pod: cannot restore pod container without --pod #15018

Closed
edsantiago opened this issue Jul 21, 2022 · 4 comments · Fixed by #15909
Closed

restore --pod: cannot restore pod container without --pod #15018

edsantiago opened this issue Jul 21, 2022 · 4 comments · Fixed by #15909
Assignees
@cdoern
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.

Comments

@edsantiago
Copy link
Member

Failing in ubuntu 2204, remote, with cgroupsv1 and runc:

podman checkpoint and restore container out of and into pod (ipc,net,uts,pid)
...
# podman-remote [options] container restore --pod NEW-POD-ID -i /tmp/checkpoint-CONTAINER-ID.tar.gz
Error: cannot restore pod container without --pod

(The discerning reader will note that --pod is specified in the command line). That error seems to come from

podman/pkg/checkpoint/checkpoint_restore.go

Lines 59 to 61 in 039deec

if ctrConfig.Pod != "" && restoreOptions.Pod == "" {
return nil, errors.New("cannot restore pod container without --pod")
}

Earlier in that test, I see this warning:

# podman-remote [options] container checkpoint -e /tmp/checkpoint-CONTAINER-ID.tar.gz CONTAINER-ID
time="2022-07-20T21:07:00Z" level=warning msg="lstat /sys/fs/cgroup/devices/machine.slice/machine-libpod_pod_OLD-POD-ID.slice/libpod-CONTAINER-ID.scope: no such file or directory"

So, yeah, seems to be cgroups-related. Something we just never tested because we haven't been testing runc.
@edsantiago edsantiago added kind/bug Categorizes issue or PR as related to a bug. remote Problem is in podman-remote labels Jul 21, 2022
@github-actions github-actions bot removed the remote Problem is in podman-remote label Jul 21, 2022
@cdoern
Copy link
Contributor

cdoern commented Jul 21, 2022

@giuseppe is the attempt to enter /sys/fs/cgroup/devices... seem weird to you? that should fail due to permissions, right? This could also be since runc separated out their device handling code.

@edsantiago edsantiago mentioned this issue Jul 21, 2022
Merged
edsantiago added a commit to edsantiago/libpod that referenced this issue Jul 22, 2022
@edsantiago
Bump VMs, to Ubuntu 2204 with cgroups v1
0a160fe 
...and enable the at-test-time confirmation, the one that
double-checks that if CI requests runc we actually use runc.
This exposed a nasty surprise in our setup: there are steps to
define $OCI_RUNTIME, but that's actually a total fakeout!
OCI_RUNTIME is used only in e2e tests, it has no effect
whatsoever on actual podman itself as invoked via command
line such as in system tests. Solution: use containers.conf

Given how fragile all this runtime stuff is, I've also added
new tests (e2e and system) that will check $CI_DESIRED_RUNTIME.

Image source: containers/automation_images#146

Since we haven't actually been testing with runc, we need
to fix a few tests:

  - handle an error-message change (make it work in both crun and runc)
  - skip one system test, "survive service stop", that doesn't
    work with runc and I don't think we care.

...and skip a bunch, filing issues for each:

  - containers#15013 pod create --share-parent
  - containers#15014 timeout in dd
  - containers#15015 checkpoint tests time out under $CONTAINER
  - containers#15017 networking timeout with registry
  - containers#15018 restore --pod gripes about missing --pod
  - containers#15025 run --uidmap broken
  - containers#15027 pod inspect cgrouppath broken
  - ...and a bunch more ("podman pause") that probably don't
    even merit filing an issue.

Also, use /dev/urandom in one test (was: /dev/random) because
the test is timing out and /dev/urandom does not block. (But
the test is still timing out anyway, even with this change)

Also, as part of the VM switch we are now using go 1.18 (up
from 1.17) and this broke the gitlab tests. Thanks to @Luap99
for a quick fix.

Also, slight tweak to containers#15021: include the timeout value, and
reword message so command string is at end.

Also, fixed a misspelling in a test name.

Fixes: containers#14833

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

A friendly reminder that this issue had no activity for 30 days.

@cdoern cdoern self-assigned this Aug 22, 2022
@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@cdoern
Copy link
Contributor

cdoern commented Sep 22, 2022

this is an issue with restore on all podman-remote versions, fixing now

cdoern pushed a commit to cdoern/podman that referenced this issue Sep 22, 2022
fix restore API endpoint
2478e32 
restore endpoint was totally ignoring --pod, it was missing from the schema and from query handling
on the api handlers side. add support for it here.

resolves containers#15018

Signed-off-by: cdoern <[email protected]>
@cdoern cdoern mentioned this issue Sep 22, 2022
Merged
@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 14, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@cdoern cdoern

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.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix restore API endpoint cdoern/podman
2 participants
@edsantiago @cdoern