criu

Overview

CRIU stands for Checkpoint/Restore in Userspace. It is a Linux utility for checkpointing a running process, container, or process tree and restoring it later from saved state. In practice, this allows a workload to be paused, its state written out, and then resumed from that state on the same host or another compatible host. (criu.org)

For a Linux distribution, the package exists to provide the upstream CRIU tool and its related components in a packaged form that can be built, tested, updated, and tracked with normal distribution workflows. NiceOS maintainers should verify any kernel- or integration-specific assumptions before relying on them. (criu.org)

Purpose and typical use cases

Typical uses include:

• checkpoint/restore workflows for containers and other Linux workloads;
• live migration and related operational workflows where process state must be moved or resumed later;
• troubleshooting, inspection, and recovery tasks that benefit from saving and restoring process state;
• integration with higher-level tooling that delegates checkpoint/restore work to CRIU. (criu.org)

Typical users include:

• system administrators operating container or process-migration workflows;
• developers working on checkpoint/restore integration or on software that embeds CRIU;
• CI/CD or platform maintainers who need to test kernel and runtime compatibility;
• security or incident-response engineers who may need to inspect checkpoint-related behavior, while still validating the exact supported workflow for their environment. (criu.org)

Upstream project

The upstream project is CRIU, hosted at the project wiki and the main source repository under the checkpoint-restore organization. The project describes itself as a Linux checkpoint/restore implementation in user space. The upstream repository also documents that CRIU is widely integrated with other container and Linux tooling, but NiceOS maintainers should verify the current integration set when packaging or updating. (criu.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifests and related metadata used by the build system;
• METADATA/ — package metadata used by the dist-git workflow;
• SBOM/ — software bill of materials material tracked by the repository.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through the manifest files in SOURCES/, which record the expected upstream sources without embedding the large archives themselves. (github.com)

Source storage and integrity policy

The repository keeps the packaging metadata in Git, not the full upstream tarballs. This keeps the repository small and makes updates easier to review. When updating the package, maintainers should check that the entries in SOURCES/ still match the upstream sources they intend to use, and that the build pulls the expected input files from the intended locations. Do not rely on stale manifests after a source change. (github.com)

Because the source integrity details are stored in manifests, NiceOS maintainers should treat those manifests as the authoritative packaging record and confirm they were regenerated or updated consistently with the spec changes. (github.com)

NiceOS maintenance notes

Before updating this package, check the following:

• verify the upstream release notes and changelog for behavior changes that may affect packaging or runtime expectations;
• verify whether the spec needs updates for new build requirements, file layout changes, or install-time paths;
• verify whether any manifests in SOURCES/ must be regenerated or replaced;
• verify whether SBOM/ or other metadata needs to be refreshed to match the new source set;
• review any kernel compatibility or feature assumptions, especially if the update changes how CRIU interacts with procfs, namespaces, or restore behavior;
• check whether downstream patches still apply cleanly and whether they still make sense after the upstream update. (criu.org)

Risks to consider during an update:

• kernel feature mismatches between the build environment and target systems;
• changed upstream file layouts that affect packaging scripts;
• regressions in restore behavior that may only appear under specific namespaces, storage layouts, or container runtimes;
• stale metadata if the source manifests or SBOM are not regenerated together with the package change. NiceOS maintainers should verify these points rather than assuming compatibility. (criu.org)

Build and verification checklist

For RPM maintenance work, a reasonable checklist is:

1. Confirm that the spec still matches the intended upstream source and packaging layout.
2. Confirm that the SOURCES/ manifests are current and point to the expected upstream inputs.
3. Review SPECS/ for patches, file lists, install paths, and conditional logic.
4. Build the package in a clean environment.
5. Run the package test or smoke-test path provided by the spec, if any.
6. Verify basic runtime behavior on a representative target kernel.
7. If feasible, run CRIU’s own kernel check or a minimal checkpoint/restore sanity test.
8. Confirm that installed documentation, binaries, and metadata are packaged as expected.
9. Review the resulting SRPM and RPM payload for unintended file changes. (criu.org)

References

• CRIU project home
• CRIU upstream source repository
• CRIU checkpoint/restore overview
• CRIU kernel check guidance (criu.org)

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/criu
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.