criu: do not set network_lock if not specified

[giuseppe]

commit c4f8c87 introduced the issue.

also improve error handling from criu APIs

Closes: #1627

[giuseppe]

@lsm5 the failures depend on some broken dependencies:

 Problem: problem with installed package lld-libs-18.1.8-1.el9.x86_64
  - cannot install the best update candidate for package lld-libs-18.1.8-1.el9.x86_64
  - package lld-libs-19.1.3-1.el9.x86_64 from appstream requires llvm-libs(x86-64) = 19.1.3-1.el9, but none of the providers can be installed
  - cannot install the best update candidate for package llvm-libs-19.1.5-2.el9.x86_64
  - cannot install both llvm-libs-19.1.3-1.el9.x86_64 from appstream and llvm-libs-19.1.5-2.el9.x86_64 from @System

[lsm5]

@giuseppe

Re: cs10, I'll do something about the catatonit dependency.

Re: rhel9, we've removed rhel jobs from our other projects because of older packages causing frequent failures. CentOS Stream works mostly well upstream.

Re: cs9, llvm 19.1.5 has been built already https://kojihub.stream.centos.org/koji/packageinfo?packageID=1160 so I guess just a matter of time before it lands in the repos. Your call if you wanna block or proceed with this PR. I can check with the maintainers about ETA, but I doubt they'd know the exact dates.

[eriksjolund]

I tried to look in the criu source code to see what kind of values criu_dump() could return.
I followed the functions:

int criu_dump(void)
which calls
int criu_local_dump(criu_opts *opts)
which calls
static int dump(bool pre_dump, criu_opts *opts)

Maybe the return value could be 1 if it comes from

https://github.com/checkpoint-restore/criu/blob/32d5a766eeb8a41e52a1c0234bbf2c5757f64b4b/lib/c/criu.c#L1580
?
Using -1 as second argument of crun_make_error() causes that function to return 0 which would be surprising.

crun/src/libcrun/error.c

Line 61 in a48818a

return -status - 1;

Sorry, this comment is a bit vague. I haven't found any reproducer for the mentioned scenario to happen.

[giuseppe]

thanks, fixed, to return the error only with ret < 0.

[giuseppe]

CI failure being addressed in: #1634

[giuseppe]

@adrianreber @flouthoc PTAL

[adrianreber]

Looks good. The network locking seems to be now correct and the return code checking is also a good addition.