How to Restart Cron in Linux (Ubuntu, Debian, RHEL and CentOS)

There is no crontab service to restart in Linux. crontab is the command and configuration format used to define scheduled jobs; the background service is named cron on Debian and Ubuntu or crond on most RHEL-family distributions.

You normally do not need to restart the service after using crontab -e, editing /etc/crontab, or adding a valid file under /etc/cron.d/. The daemon detects changed schedules automatically.

Restart cron or crond only when the daemon is stopped, unhealthy, or you are troubleshooting the service itself. Cronie monitors stored crontabs and reloads changed schedules; Debian’s cron package similarly describes cron as reading the crontab files and executing scheduled commands.

Quick reference

After a normal crontab -e edit, save the file and confirm with crontab -l. A service restart is not part of that workflow.

Do You Need to Restart Cron?

Use this table before you touch systemctl. Ordinary schedule edits do not need a daemon restart.

Cronie monitors user crontabs, /etc/crontab, /etc/anacrontab, and files under /etc/cron.d/. When inotify is available, it detects file changes through filesystem notifications; otherwise, it checks modification times every minute and reloads changed crontabs. The Cronie manual documents both inotify-based detection and the minute-based fallback, and states that changed crontabs are reloaded automatically with no need to restart cron after modification.

On Debian-family systems, /etc/crontab and files in /etc/cron.d/ are monitored for changes, and cron checks modification times each minute when determining what to reload. See the Debian cron man page for that behavior.

Crontab vs Cron vs crond

crontab -e edits the current user’s schedule. /etc/crontab is a system-wide crontab with an additional username field. Files under /etc/cron.d/ also use the system-crontab format. /etc/cron.hourly, .daily, .weekly, and .monthly are periodic script directories managed according to the distribution’s cron/anacron setup.

The Debian crontab manual states that user crontabs should be managed with the crontab command rather than directly editing spool files. For field syntax and examples, see the crontab command cheat sheet.

Check the Cron Service Before Restarting

Start with detection rather than assuming the service name. One of the two units should respond on a typical server:

systemctl status cron 2>/dev/null || systemctl status crond

On an RHEL-family host, cron.service is absent and crond.service is active:

● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-07-11 16:42:12 IST; 406ms ago
   Main PID: 4706 (crond)

That active (running) line means the scheduler daemon is up; you still restart only when its state or logs show a real service problem.

Debian, Ubuntu and Linux Mint

sudo systemctl status cron

sudo systemctl is-active cron

sudo systemctl is-enabled cron

On Debian and Ubuntu, is-active should print active and is-enabled should print enabled when cron is installed and set to start at boot.

RHEL, Rocky Linux, AlmaLinux and CentOS Stream

sudo systemctl status crond

sudo systemctl is-active crond

sudo systemctl is-enabled crond

On the test host both checks returned active and enabled.

Process and package checks

List installed cron units:

systemctl list-unit-files | grep -E '^(cron|crond)\.service'

Sample output:

crond.service                                                             enabled         enabled

Confirm the crontab utility is installed:

command -v crontab

/usr/bin/crontab

How to Restart Cron on Linux

Ubuntu and Debian

Restart the daemon when the service is stopped or unhealthy:

sudo systemctl restart cron

The command exits silently on success. Confirm the unit came back up:

sudo systemctl status cron --no-pager

Look for Active: active (running) in the status block.

RHEL-family distributions

On Rocky Linux 10.2 the equivalent unit is crond:

sudo systemctl restart crond

Verify immediately afterward:

sudo systemctl status crond --no-pager

Sample output:

● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-07-11 16:42:12 IST; 406ms ago
   Main PID: 4706 (crond)

Start, stop and enable

On older init scripts you may still see sudo service cron restart or sudo service crond restart. Those are compatibility paths for non-systemd or legacy tooling—not the primary workflow on current systemd-based releases. Do not treat direct /etc/init.d/ calls as equal modern alternatives.

Does Cron Support Reload?

Cron normally detects crontab changes itself, so an explicit reload is generally unnecessary for schedule updates. systemctl reload only works when the installed unit exposes a reload operation, and support varies by distribution, cron implementation and package. Do not assume cron.service and crond.service both support reload.

Check whether the unit advertises reload support:

systemctl show crond -p CanReload

On Rocky Linux 10.2 with Cronie:

CanReload=yes

The cron unit is not present on that host:

systemctl show cron -p CanReload

CanReload=no

CanReload=yes does not necessarily mean “reload all cron schedules.” On the tested Cronie service, the systemd reload action sends SIGHUP. Cronie normally uses this signal to close and reopen its log file; ordinary crontab changes are detected separately through inotify or modification-time checks.

Do not run systemctl reload crond merely after crontab -e.

Do not restart or reload cron merely to activate a changed schedule. First verify the crontab file and wait for the next matching minute. Restart the daemon only when its service state or logs show an actual daemon problem.

Verify That the Updated Cron Job Is Loaded

User crontab

List the current user’s installed lines:

crontab -l

Sample output:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
* * * * * date >> /tmp/cron-test.log 2>&1

For another user:

sudo crontab -u username -l

System schedules

sudo cat /etc/crontab

List drop-in job files:

sudo ls -l /etc/cron.d/

Sample output:

total 4
-rw-r--r--. 1 root root 128 Jan 14 05:30 0hourly

Create a temporary verification job

Add a one-minute test line with crontab -e:

* * * * * date >> /tmp/cron-test.log 2>&1

Watch the log file:

tail -f /tmp/cron-test.log

New timestamps should appear once per minute when the schedule is valid. Remove the test line and delete /tmp/cron-test.log when you are done.

Cron Is Running but the Job Does Not Execute

When systemctl status shows the daemon is healthy, look at the job itself. Restarting cron rarely fixes syntax, path, or permission problems.

Check the schedule syntax

crontab -l

For /etc/crontab and /etc/cron.d/, remember the username field:

# minute hour day month weekday user command
0 2 * * * root /usr/local/sbin/backup.sh

A user crontab does not include that username column:

0 2 * * * /usr/local/sbin/backup.sh

Use absolute paths

Cron runs with a restricted environment:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Prefer:

0 2 * * * /usr/bin/python3 /opt/scripts/report.py

rather than:

0 2 * * * python3 /opt/scripts/report.py

Check ownership and permissions

ls -l /path/to/script.sh

sudo chmod +x /path/to/script.sh

Files under /etc/cron.d/ should normally be owned by root and must follow the implementation’s filename and permission rules. On Debian-family systems, files under /etc/cron.d/ must be owned by root, must not be group- or other-writable, and normally use names containing only letters, numbers, underscores, and hyphens. Files in /etc/cron.d/ do not need the executable bit. Scripts under /etc/cron.daily/ do need to be executable—that distinction trips up many first-time cron setups.

Check line endings and interpreter

file /path/to/script.sh

head -1 /path/to/script.sh

Windows CRLF line endings and a missing shebang (#!/bin/bash) are common reasons a script works in your shell but not from cron.

Capture standard output and errors

* * * * * /path/to/script.sh >> /tmp/script-cron.log 2>&1

Cron may log only that it attempted to run the command; the log file shows what the script printed.

Check SELinux where applicable

On RHEL-family systems:

getenforce

Enforcing

sudo ausearch -m AVC -ts recent

Fix the policy or file context rather than disabling SELinux.

Check time and timezone

timedatectl

Local time: Sat 2026-07-11 16:42:11 IST
           Universal time: Sat 2026-07-11 11:12:11 UTC
                Time zone: Asia/Kolkata (IST, +0530)

date

Jobs scheduled around DST changes, after timezone edits, or on VMs with clock drift may appear to “skip” even when cron is healthy.

Check cron logs

On Debian and Ubuntu, depending on logging configuration:

sudo journalctl -u cron --since today

sudo grep CRON /var/log/syslog

On RHEL-family distributions:

sudo journalctl -u crond --since today

sudo tail -f /var/log/cron

Recent journal lines from the test host:

sudo journalctl -u crond -n 50 --no-pager

Jul 11 16:21:02 rocky1 crond[900]: (CRON) INFO (running with inotify support)
Jul 11 16:21:02 rocky1 crond[900]: (demo_cron) ORPHAN (no passwd entry)

The exact log file depends on the distribution and logging configuration. A successful cron log entry does not prove your script completed successfully—it may only show that cron tried to launch it.

When Restarting Cron Is Actually Appropriate

Restart may be reasonable when:

• cron.service or crond.service is failed
• the daemon is running but no schedules are being evaluated
• the cron package or daemon-level configuration was changed
• the service was upgraded and the package manager did not restart it
• logs indicate a daemon-level fault
• you are recovering after a damaged or replaced service process

Restart is normally not a fix for:

• invalid cron syntax
• missing executable permissions
• relative paths
• missing environment variables
• wrong username field
• malformed /etc/cron.d/ filenames
• command failures
• SELinux denials
• timezone misunderstandings

Summary

There is no crontab service to restart. User crontabs, /etc/crontab, and valid files under /etc/cron.d/ are normally detected automatically by the cron daemon.

Use systemctl restart cron on Debian and Ubuntu or systemctl restart crond on RHEL-family distributions only when the daemon itself is stopped, failed, or unhealthy. When one scheduled job does not run, check its syntax, paths, permissions, environment and logs before restarting the service.

References

• Cronie manual (cron.8)
• Debian cron man page
• Debian crontab man page
• Red Hat Enterprise Linux — configuring scheduled tasks
• systemd.service — reload behavior