crond

Start daemon in the background and check for scheduled commands

$ crond

$ crond -n

$ crond -s

$ crond -p

$ crond -P

crond [OPTIONS]

Note: crond is typically started automatically as a system service at boot time and not usually invoked directly by users.

-n
    Runs crond in the foreground, preventing it from detaching from the controlling terminal. This is primarily useful for debugging purposes, allowing output to be seen directly on the console.

-x flags
    Activates debugging output. The flags argument is a comma-separated list of debug categories (e.g., proc, pars, load, sch, test, misc, ext, full) or a bitmask, which vary by crond implementation. This provides verbose information about internal operations to standard error.

-c directory
    Specifies the directory where user crontab files are stored. The default location is typically /var/spool/cron. This option is rarely used outside of testing or specialized configurations.

The crond command refers to the cron daemon, a background process on Unix-like operating systems responsible for executing commands or scripts automatically at specified intervals.

It continuously monitors configuration files, primarily user-specific crontabs located in /var/spool/cron/ and system-wide crontabs such as /etc/crontab and files within /etc/cron.d/, as well as scripts placed in directories like /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly.

Every minute, crond wakes up to check if any scheduled tasks are due for execution. When a task is run, its standard output and standard error are typically mailed to the user who owns the crontab (or a specified MAILTO address). crond is crucial for automating routine system maintenance, backups, log rotation, and other time-based administrative or user tasks, ensuring systems remain efficient and well-managed.

crond must be running for scheduled tasks to execute. Its status can usually be checked via systemctl status cron or systemctl status cronie.

Cron jobs execute with a minimal environment. It is often necessary to explicitly set PATH and other environment variables within the crontab entry or the script it executes.

Timezone considerations: crond operates based on the system's local time by default. Explicitly setting the TZ variable in a crontab can override this for specific jobs.

All output (stdout and stderr) from a cron job is typically emailed to the user who owns the crontab or the address specified by the MAILTO variable. If not handled, this output might be lost.

Ensure crontab files have correct permissions (e.g., 600 for user crontabs, owned by root) to prevent security vulnerabilities.

Each line in a crontab file typically consists of six fields, separated by spaces or tabs:
minute hour day_of_month month day_of_week command

Fields:
Minute (0-59)
Hour (0-23)
Day of Month (1-31)
Month (1-12 or Jan-Dec)
Day of Week (0-7 or Sun-Sat, where both 0 and 7 are Sunday)
Command to be executed

Wildcards (*) represent "every" unit. Ranges (1-5), lists (1,3,5), and step values (*/5) are also supported.

Additionally, some special strings exist for convenience: @reboot, @yearly, @annually, @monthly, @weekly, @daily, @hourly, and @midnight.

crond manages two primary types of crontab files:

User-specific Crontabs: Managed by individual users via the crontab -e command. These files are typically stored in /var/spool/cron/<username>. Each user has their own crontab, and commands are executed with their permissions.

System-wide Crontabs: Found in /etc/crontab and files within the /etc/cron.d/ directory. These are typically managed by the system administrator or package installations. Unlike user crontabs, entries in these files often include an additional field specifying the user under whom the command should run. Additionally, scripts placed in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly are also executed by crond, usually via entries in /etc/crontab itself.

The concept of cron, short for "chronos" (Greek for time), dates back to early versions of Unix in the late 1970s. The daemon component, crond, evolved significantly over time. Paul Vixie's Vixie-cron in the late 1980s became a widely adopted standard, introducing features like per-user crontabs and robust logging that were missing in earlier implementations.

Modern Linux distributions often use cronie, a fork of Vixie-cron that aims for improved security, performance, and compatibility. crond remains a fundamental utility for system automation, demonstrating the enduring need for reliable, time-based job scheduling in Unix-like operating systems.

crontab(1): Manage user-specific cron tables., cron(8): General manual page often referring to the cron system., anacron(8): Execute commands periodically on systems that are not always running., at(1): Schedule commands to run once at a specific time., batch(1): Execute commands when system load permits., systemctl(1): Control and query the systemd system and service manager (used for managing the cron service).