Bug 2055781

Summary: criu doesn't report error when there is file lock exist in container
Product: Red Hat Enterprise Linux 9 Reporter: Joy Pu <ypu>
Component: criuAssignee: Adrian Reber <areber>
Status: CLOSED WONTFIX QA Contact: Chao Ye <cye>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: ajia
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-17 07:28:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joy Pu 2022-02-17 15:56:55 UTC
Description of problem:
When we do checkpoint with file lock inside container but without --file-locks flag, criu can not report error as expected.

Version-Release number of selected component (if applicable):
criu-3.15-13.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. start a container with a file lock inside
# podman run -it --security-opt seccomp=unconfined -d --ip 10.88.158.133 --name test_name quay.io/libpod/alpine:latest flock test.lock sleep 100
e4bd6118abf9b1ef0cfaf3bb4c94e7e7d0c961e5635e4eec1d77d3427e446932
2. make a checkpoint without --file-locks
# podman container checkpoint test_name
e4bd6118abf9b1ef0cfaf3bb4c94e7e7d0c961e5635e4eec1d77d3427e446932



Actual results:
checkpoint can be made successfully

Expected results:
An error message should be raise to remind user to check the dump.log and create the checkpoint with --file-locks option

Additional info:
other rpms in my env:
runc-1.1.0-2.el9.x86_64
crun-1.4.2-1.el9.x86_64
podman-4.0.0-0.31.el9.x86_64

Comment 2 RHEL Program Management 2023-08-17 07:28:43 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.