conmon

Overview

conmon is an OCI container runtime monitor. In practice, it sits between a container manager such as Podman or CRI-O and the OCI runtime used to start a container. It tracks the container process, keeps the container's streams available for attachment, and records exit status after the container ends. (github.com)

For a Linux distribution, this package exists because container managers depend on conmon to supervise container lifecycles. NiceOS packages it as a separate RPM so that container tooling can be updated, rebuilt, and verified independently. That relationship is visible in upstream Podman documentation, which describes Podman starting conmon before the OCI runtime. (docs.podman.io)

Purpose and typical use cases

Typical use cases include:

• running and supervising containers started by Podman or CRI-O;
• keeping container standard streams available for later attachment;
• persisting container logs or forwarding them to the systemd journal, depending on configuration;
• recording container exit information for the managing program. (github.com)

Typical users of this package are:

• system administrators who deploy or troubleshoot container hosts;
• developers who run local containers with Podman;
• CI/CD maintainers who need predictable container execution on build hosts;
• platform or container engineers who package the runtime stack for a distribution. (github.com)

Upstream project

Upstream source and project information are maintained in the containers/conmon repository. The upstream project describes conmon as a small monitoring program for a single container, written in C and intended to stay lightweight. NiceOS maintainers should verify any upstream behavioral changes that affect runtime integration before relying on them in packaging. (github.com)

Dist-git repository contents

This dist-git repository is organized for RPM packaging work:

• SPECS/ contains the RPM spec file and related packaging logic.
• SOURCES/ contains metadata and manifest files used to describe upstream sources.
• METADATA/ contains package metadata used by the dist-git workflow.
• SBOM/ contains software bill of materials material when it is maintained for the package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, so the repository stays small and reviewable while still recording what source should be fetched. The exact manifest format should be checked in this repository if it changes. (github.com)

Source storage and integrity policy

NiceOS keeps the upstream source payload out of the Git tree on purpose. Only the packaging metadata and the source manifest live here. That means a package update should always be checked against the manifest entries in SOURCES/, rather than by expecting the full tarball or archive to be committed.

Before trusting an update, confirm that:

• the manifest still points to the intended upstream source;
• the upstream tag, commit, or release reference is what the package is meant to follow;
• any source regeneration step did not unintentionally change packaging inputs;
• the packaged source still matches the upstream project release or snapshot being tracked.

If the repository uses additional verification files or generated metadata, NiceOS maintainers should review them as part of the update instead of assuming they remain valid.

NiceOS maintenance notes

Before updating this package, check the following:

• upstream release notes or repository changes for behavior that may affect Podman, CRI-O, or other container managers;
• whether the spec file needs changes for new build flags, file locations, or install paths;
• whether SOURCES/ manifests must be regenerated or refreshed;
• whether SBOM/ or other metadata files need to be updated;
• whether the update changes runtime expectations for packages that depend on conmon.

Risks to consider:

• container lifecycle regressions if upstream changes how conmon supervises runtime processes;
• packaging drift if install paths or bundled scripts change upstream;
• test failures if the distro build environment differs from upstream assumptions;
• downstream breakage in Podman- or CRI-O-based workflows if the installed helper binary moves or behaves differently.

NiceOS maintainers should verify these points before publishing an update, especially when the upstream change touches container attachment, logging, exit handling, or process supervision.

Build and verification checklist

A practical RPM maintainer checklist:

• inspect the spec diff for new build requirements or file list changes;
• confirm the source manifest in SOURCES/ matches the intended upstream source;
• rebuild the SRPM and RPMs in a clean environment;
• review build logs for missing dependencies, path mismatches, or unexpected patch failures;
• run the package test suite if one is defined in the spec or upstream build system;
• verify installed files, permissions, and ownership;
• confirm that the package still satisfies the expectations of Podman or CRI-O in the target distro;
• check for stray artifacts in the build root;
• if the package ships SBOM material, refresh and review it alongside the build.

References

• Upstream project repository
• Podman documentation: conmon behavior in container startup
• Podman project repository

Russian documentation

See README_RU.md for the Russian documentation.

Dist-git repository notes

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