How to List Cron Jobs: Master Cron on Linux

Cron jobs are commands and scripts that the system runs periodically. Just as with cron on reboot, you can also use the systemd service manager to accomplish the same thing, but cron can be used by anyone and doesn’t require special permissions. It’s also easier to understand than systemd, but isn’t as integrated into the OS. In this tutorial, I’ll show you how to list cron jobs, not just for the current user, but systemwide. For this, you need sudo permissions, without necessarily being logged in as root.

I’ll also show you the difference between cronjobs and systemd, and look at alternative scheduling tools.

How to List Cron Jobs on Linux for the Current User

To list the cronjobs for the user that’s currently logged into Linux, type the following:

crontab -l

This will give an output that looks like this:

The above is a quick cronjob that I created to simply print the date to a text file. To ensure that the file doesn’t get too large, I’ve used the “>” operator instead of “>>”, which would have appended the date to the file instead of overwriting it.

As you can see, I don’t have any important cron jobs running. This is because as the current user, you’ll probably need to create them yourself unless your system admin has done it for you automatically. But if you want to say, clean your MySQL database every week, then you can add cron jobs by typing the following command:

crontab -e

How to List System-Wide Cron Jobs

Unlike with user cron jobs, you can’t always view the cron jobs that are systemwide, unless you have sudo permissions. This is because they contain sensitive information about how the server is run, and a regular user wouldn’t derive any value from seeing them, anyway.

But if you have sudo permissions, there are a few locations in Linux where you can find system-wide cron jobs. Here they are:

1. /etc/crontab
2. /etc/cron.hourly/
3. /etc/cron.daily/
4. /etc/cron.weekly/
5. /etc/cron.monthly/
6. /etc/cron.d/

Out of these, /etc/crontab is a file and you can view it like this:

sudo cat /etc/crontab

When I enter the above command, I get an output like this:

Once the commended lines with “#” end, you can see the list of cron jobs. Some of them spill over into the next line, so it might be a bit hard to read, but the syntax is clear. Notably, you see that they reference other cron areas of cronjobs. So if you’re not sure where the various cron jobs are located on your Linux system, it might be worth it to start your search at /etc/crontag because it gives you clues to the locations of the others.

Hourly, Daily, Weekly, and Monthly Cron Jobs

While /etc/crontab is a file, the others mentioned in the list are directories. And these are:

1. etc/cron.hourly/
2. /etc/cron.daily/
3. /etc/cron.weekly/
4. /etc/cron.monthly/

As the list implies, these are the folders in which you place the scripts that you want to run periodically, based on the name of the folder. For example, if I list the contents of the /etc/cron.daily folder on my Linux server, I get the following:

These scripts, since they’re located in the “daily” folder, will run every day. The exact time at which these scripts are run depends on the time configured in /etc/crontab. From the earlier screenshot, you can see that the daily cron time had a schedule signature of:

25 6 * * *

This means that the job will run every day at 6:25 am. You can similarly get the times at which the other weekly and monthly scripts run.

The availability of these folders makes it easy to run periodic scripts without manually editing crontab. If you simply want a script or command to run every day without bothering too much about what time it runs, then simply add it to the /etc/cron.daily folder and you’re done. Ditto for the monthly and weekly scripts. Of course, if you want a more specific schedule, just at it to /etc/crontab manually.

Listing the Cron Jobs in /etc/cron.d

In addition to /etc/crontab and the periodic folders, there exists another folder called /etc/cron.d/ which contains folders and files of additional cron jobs. For example, on my Linux system, there’s a folder called /etc/cron.d/e2scrub_all, which is a provision to regularly check the Linux file system for errors.

You can list all the folders in /etc/cron.d/ like you would any other directory:

ls /etc/cron.d

You might wonder why have another folder like cron.d, when you have the systemwide cron jobs located in crontab anyway. The reason for this design decision is that cron.d provides a way to separate cron jobs related to system administration and package management. For example, a package might decide that it needs to initiate a periodic task for a system process, and Linux wanted to give these processes a place to put their cron jobs so that they don’t get mixed up with others.

Particularly since these packages will be constantly changing their jobs, the cron.d folder allows for the abstraction of package and system-level jobs from the more user-facing ones.

Another important difference between cron.d and crontab, is that in cron.d, along with the standard syntax of the cron job, it also specifies the username under which the command must be run.

For example, on my Linux system, the following cron command is located in the e2scrub_all file under the cron.d folder:

30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron

You can see that it’s almost the same syntax as a regular cron job, except that the user “root” is mentioned as the account under which the task must be run. This is in contrast to the user-facing crontab, where the processes are run under the name of the user who owns the crontab file.

Contrast with systemctl list-timers

Like the cron jobs that you can list with crontab, there is another service that allows various timers to run on Linux systems, and that is systemd. Systemd is a much more comprehensive timing solution, but it’s usually reserved for system services, whereas crontab is more for single, standalone commands.

To see what timers are included with systemd, use the following:

systemctl list-timers

Running the above looks like this:

As you can see, it’s more of a constantly running setup compared to cron jobs, which are executed at specific times. Moreover, the times in systemd can be a lot more detailed with users being allowed to specify the time to run since the last boot and even calendar-based scheduling with much tighter controls over the run times beyond mere time and date.

Another benefit of systemd is that the events in systemd are much more structured from a logging point of view, and you can query the logs, as opposed to cron jobs whose output is usually just an e-mail to the user.

Conclusion

Linux systems have a variety of locations containing the various cron jobs, and you can easily schedule a periodic standalone task by placing it in one of the dedicated daily, weekly, or monthly folders. Cron jobs are for simple tasks, whereas for more complex, system-integrated tasks, we need to use the systemd service and list the timers using systemct.