cronie

Overview

Cronie is the upstream project for the standard cron daemon used to run commands at scheduled times on Unix-like systems. In a Linux distribution, this package provides the scheduler and related tools that administrators use to automate recurring maintenance, housekeeping, reporting, and other timed jobs.

For users, Cronie is usually invisible until a scheduled task needs to run. For maintainers, it is the package that defines how classic cron-style scheduling is delivered, packaged, and integrated with the rest of the system.

Purpose and typical use cases

Cronie is typically used for:

• periodic system maintenance jobs
• log rotation helpers and cleanup tasks
• backups and exports
• recurring application jobs
• simple automation on servers and workstations

Typical users include:

• system administrators who manage host-level scheduled jobs
• developers who need predictable background task scheduling in test or production environments
• CI/CD and automation maintainers who run timed jobs on build or deployment hosts
• security engineers who review scheduled privileged tasks and execution contexts

Cronie is a good fit when a workload is naturally expressed as a time-based shell command or script and does not require a larger job orchestration system.

Upstream project

The upstream project is the cronie-crond/cronie repository. Its own project description identifies Cronie as the cron daemon project, and the repository includes the daemon, man pages, build system files, and packaging-related upstream metadata. (github.com)

Cronie implements the traditional cron scheduling model described by the crontab(5) manual page: jobs are defined with a schedule expression and then executed by the cron daemon at the appropriate time. (man7.org)

NiceOS maintainers should verify upstream release notes and local patch applicability before importing a new upstream snapshot or release tag. The upstream project publishes releases on its GitHub release page. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec file(s) and related packaging logic
• SOURCES/ — source metadata, manifests, and other tracked source-side files
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials material, when maintained for the package

The repository intentionally does not store large upstream source archives in Git. Instead, source integrity is tracked through manifest files in SOURCES/. This keeps the repository smaller and makes updates easier to review while still preserving the packaging-side record needed to verify imported sources.

Source storage and integrity policy

For this package, NiceOS expects the source archive itself to be stored outside the Git history, while SOURCES/ contains the manifest data used to identify and verify the imported source content.

Before updating the package, maintainers should confirm that:

• the manifest points to the intended upstream source set
• the upstream tag or release being imported is the one actually expected
• any local patches still apply cleanly
• the packaging metadata still matches the installed files and build outputs

Do not rely on stale source manifests if the upstream project changes its release layout, auxiliary files, or build inputs. Verify the source list and regeneration requirements each time.

NiceOS maintenance notes

Before submitting an update, check the following:

• review the upstream changelog or release notes for behavior changes
• compare local patches against upstream changes and drop patches that are no longer needed
• verify whether any spec sections, file lists, or install paths need adjustment
• regenerate packaging metadata if the upstream tarball content or source layout changed
• review service files, sysconfig files, man pages, and any auxiliary scripts if they are shipped by the package
• check whether the update changes cron behavior, default paths, or configuration parsing in a way that affects existing deployments
• consider whether the update could affect scheduled jobs that rely on current daemon behavior, mail handling, or PAM integration; if the exact impact is not clear from upstream notes, NiceOS maintainers should verify it before relying on the update

If the package carries an SBOM, confirm that it still matches the packaged file set after any source or spec change.

Build and verification checklist

For RPM maintenance, a practical update check should include:

• confirm the upstream source reference used by SOURCES/ is the intended one
• rebuild the SRPM and check that the spec consumes the expected source set
• run the package build in a clean environment
• inspect build logs for missing dependencies, configure failures, and install-path mismatches
• verify that installed binaries, man pages, service units, and configuration files land in the expected locations
• run any available package test suite or smoke tests
• if there are cron-specific tests or sample jobs, confirm that the daemon starts and parses schedules as expected
• verify that packaging changes do not overwrite user-managed configuration
• review whether file permissions, ownerships, and SELinux or PAM-related integration points still behave as expected on NiceOS

If no automated tests are available upstream, NiceOS maintainers should document the manual checks they used for the update.

References

• Cronie upstream repository
• Cronie releases
• crontab(5) manual page

Russian documentation

See README_RU.md for the Russian documentation.

Dist-git repository notes

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