What Time Does cron.daily Run

1. Introduction

On Linux systems, automation plays a crucial role in maintaining system stability and efficiency. One of the most commonly used automation tools is cron, a time-based job scheduler. Most importantly, it enables us to automate tasks like backups, log rotations, and updates.

Interestingly, cron.daily has a specific time of day it runs at, but this isn’t the whole story. In this tutorial, we’ll review a bit of how cron works, how it cron interacts with components like anacron and systems, and how this affects cron.daily‘s scheduling. Then, we’ll discover how to manage, troubleshoot, and customize daily scheduled jobs. Last but not least, we’ll also cover practical examples and real-world use cases.

2. A cron.daily Overview

In this section, we’ll review the fundamentals of cron and cron.daily itself.

2.1. Reading a crontab

In essence, cron is a system daemon used to execute scheduled tasks, known as cron jobs, at specific times or intervals. It’s part of virtually every Unix-like system and is an essential part of system administration.

If we were to look at a listing of cron declarations, we’d see things like:

30 2 * * * /usr/local/bin/backup.sh

Each of these has an important meaning:

• 30: minute — at the 30th minute
• 2: hour — at 2 AM
• * * * resembles every day, every month, every day of the week
• /usr/local/bin/backup.sh is the command to execute

One important thing to highlight and understand is that cron uses a daemon process, crond, to read configuration files called crontabs and execute the indicated commands.

2.2. Understanding cron.daily

The /etc/cron.daily directory is part of the system’s automated maintenance infrastructure. Accordingly, it contains scripts that are executed once per day, typically for system upkeep.

There are a variety of tasks that this directory is responsible for executing. For example, these tasks can cover:

• system maintenance
• scanning system health
• making sure healthy updates are taking place
• rotating logs
• updating file indexes like mlocate.db
• removing temporary or stale files

Next, let’s check out how to list the files in the /etc/cron.daily directory and understand what to expect:

# ls -l /etc/cron.daily/
total 28
-rwxr-xr-x 1 root root  724 Apr  1 00:00 apt
-rwxr-xr-x 1 root root 1032 Mar 15 03:15 aptitude
-rwxr-xr-x 1 root root  358 Jan 22 05:30 bsdmainutils
-rwxr-xr-x 1 root root  987 Feb  8 12:45 dpkg
-rwxr-xr-x 1 root root  412 Nov 10 18:20 logrotate
-rwxr-xr-x 1 root root  651 Dec  5 09:10 man-db
-rwxr-xr-x 1 root root  589 Mar 28 21:05 mlocate

From the output above, we can take away some important considerations:

• Distribution specific: The exact files present in /etc/cron.daily will vary depending on the Linux distribution (for example, Ubuntu, Fedora, or CentOS) and the software packages installed
• Executable scripts: All the files listed here typically have execute permissions (x in the permissions string) because they are meant to be run automatically by the cron daemon on a daily basis

Finally, these scripts are usually owned by the root user since they often perform system-level maintenance tasks that require administrative privileges.

2.3. Other cron Files

Note that cron.daily is just one of a few files that indicate a specific interval for a collection of tasks:

These are all executed using run-parts and can be configured similarly.

3. The cron.daily Crontab Defaults

In this section, we’ll look at where cron.daily‘s schedule is configured.

3.1. The cron.daily Crontab

In general, we can define cron jobs at three main levels:

1. user crontabs: we can create them using the crontab -e command
2. system crontabs: located at the /etc/crontab directory
3. cron directories: this includes /etc/cron.hourly and /etc/cron.daily

Given that, the simplest way to discover when cron.daily is scheduled is to view the system crontab like so:

# cat /etc/crontab | grep cron.daily

Which, on most systems by default, will output:

25 6 * * * root run-parts /etc/cron.daily

Particularly, this line of code tells cron to execute all executable scripts in /etc/cron.daily at 6:25 AM as the root user, which is a common Linux default.

Note also that run-parts is the tool that executes each script in a directory. It skips files that aren’t executable or contain dots or invalid characters.

3.2. Using anacron

Note that if we see something instead like:

25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Then we should also consult our anacron configuration; its behavior is defined in /etc/anacrontab:

# period  delay  job-identifier  command
1         10     cron.daily      nice run-parts /etc/cron.daily

By analyzing the code snippet above, we conclude that anacron:

• 1: runs cron.daily once a day
• 10: it waits 10 minutes after booting
• run-parts: it executes all scripts in /etc/cron.daily

3.3. Using systemd With cron

Finally, in some modern Linux distributions, traditional cron jobs — including cron.daily — may be managed by systemd timers instead of the classic cron or anacron setup.

We can check this using  systemd list-timers:

$ systemctl list-timers | grep cron.daily

If we something listed, it means systemd is handling those scheduled jobs.

4. Scheduled Time vs Execution Time

cron.daily‘s scheduled time and execution time may be different. Several factors influence this:

• Whether the system uses cron or anacron
• Whether the system is up and running at the scheduled time
• Additional distribution-specific behavior

4.1. cron vs anacron

In the first case, cron assumes that the system is always up. This means that if the system is down at the scheduled time, cron.daily tasks won’t run.

On the other hand, anacron handles tasks for systems that shut down (like desktops or laptops). This means that if the system was off at the scheduled time, cron.daily tasks will run 10 minutes after the next boot.

Let’s see a crontab where both may come into play:

25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

This command says that if anacron is present, have it run manage execution, ensuring it will be run regardless of the system being down at the scheduled time. Otherwise, use cron.

4.2. Checking cron.daily‘s Output

To verify if cron.daily has run successfully, we can utilize a variety of options. Let’s explore two of them:

# journalctl -u cron.service

The first option is to utilize the journalctl command for log inspection.

Or second, we can utilize the grep command and search within the syslog file:

# grep anacron /var/log/syslog

In case we opted to use option 1 or option 2, we’ll have to search for entries similar to these lines:

Apr  7 06:25:01 myhost anacron[1012]: Job `cron.daily' started
Apr  7 06:25:02 myhost anacron[1012]: Job `cron.daily' terminated

Analyzing the code snippet above, we have a definitive timestamp of the start and end times of the execution of cron.daily.

5. Editing the cron.daily Schedule

To customize the execution time of cron.daily, we have two options as well.

First, we can modify /etc/anacrontab:

1    30   cron.daily   nice run-parts /etc/cron.daily

This will execute cron.daily 30 minutes after boot.

On the other hand, we can modify /etc/crontab in case there is no anacron:

30 7 * * * root run-parts /etc/cron.daily

In this case, cron.daily executes at 7:30 AM.

Finally, if we are using systemd, we can configure a systemd timer.

6. Troubleshooting Best Practices

In this section, we’ll explain some troubleshooting steps when assessing why cron.daily might not be running:

1. check file permissions using ls -l /etc/cron.daily/to make sure scripts are executable
   
2. check filename validity and avoid dots or invalid characters
3. check logs through journalctl or /var/log/syslog
4. check run-parts using run-parts –test /etc/cron.daily
5. check anacron status using systemctl status anacron.service

7. Conclusion

In this tutorial, we explored when cron.daily runs, and that it’s more than just knowing the default time. We explored how its execution depends on the presence of anacron, the system’s uptime, and configurations found in files like /etc/crontab and /etc/anacrontab.

Moreover, we also discussed what kinds of tasks reside in /etc/cron.daily, how they’re triggered using run-parts, and how distributions and setups may vary.

By learning how to inspect logs, adjust schedules, and troubleshoot common issues, we gain the tools to manage daily maintenance jobs with confidence and flexibility.