Have you watched Suits? I’m on Season 2 and envious of Harvey Specter. While I admire his obvious talents, it’s the personnel at his disposal I’m jealous of. I mean, I’d kill (not literally, of course) to have an assistant as organized as Donna Paulsen and an associate as brilliant as Mike Ross.
Donna, in particular, is a dream employee (though let me be clear, I’m strictly talking about her skills here). With her on your team, you’re guaranteed to perform all your tasks on time. If you’re a diehard Unix user, you can think of cron jobs as your very own Donna.
Cron jobs help automate regular tasks like system maintenance and monitoring at specified times or intervals.
You might deny it, but we all need a helping hand. If you haven’t heard of cron jobs yet, it’s time for you to set up your very first one. And if you haven’t watched the show yet, you’re really missing out. Read on, because this isn’t the last time I’m going to mention Donna!
-
Navigate This Article:
The Basics of Cron Jobs
Let’s look at cron jobs from another perspective. If you don’t have the time and energy to do household chores, you need to hire a housekeeper. I do my part: I make my bed, do the laundry, prepare the occasional meal, water the plants, take out the trash, and wash the dishes before I go to bed. But that’s not enough.
You can think of cron jobs as a housekeeper for your Unix system. For example, if you want to clean your “house” every day, you can schedule a cron job to tidy things up at, let’s say, 3 AM. This digital housekeeper will throw away anything that’s been sitting for too long (temp files) and keep your computer from getting bogged down with junk.
The Cron Daemon
Don’t confuse daemons for demons. Once you’ve scheduled a task, the cron demon… er… daemon executes it at the specified time. In other words, the cron daemon is the real Donna. It works in the background while the cron job takes all the credit. How’s that for a twist?
Simply put, the cron daemon is the conductor of the orchestra. It ensures each musician (cron job) plays at the right time!
History of Cron
The original version of cron was created way back in the 1970s; It’s almost as old as my father (he was born in the summer of 1969)! Interestingly, the name “cron” originates from a Greek word, “chronos,” which means time.
After all, cron jobs save time. In its early days, you could only schedule cron jobs to run basic tasks, such as sending emails. Now, cron jobs can handle even the most complex tasks. For example, you could schedule a cron job to back up a MySQL database, compress it, and then delete old backups to save space. Neat, right?
How Do Cron Jobs Work?
Now that you know what cron jobs and the cron daemon are, I’m going to introduce you to the final piece of the puzzle: the crontab file. I’m certain you’ll have a complete understanding of how cron jobs work by the end of this section.
Crontab File
I think you’ve had enough of the Donna comparisons., so let’s get real. You can think of a crontab file as a “diary” that contains the schedules for cron jobs. Basically, if you want to create a cron job, you’ll have to “open” your diary and “write down” your cron job (don’t forget to save your changes!).
A user crontab file is like your personal diary (you can access it using the “crontab – e” command). A system-wide crontab file, on the other hand, can only be edited by system administrators. It’s like the class register your teacher maintains.
Cron Daemon Workflow
Let’s put together all the pieces of the puzzle. The cron daemon is always on its toes — it starts running in the background as soon as your computer boots up. It monitors your crontab file and all other user and system-wide crontab files in real time, executing cron jobs at their specified times.
After executing a cron job, it may log the action (I really suggest you maintain a log). This is useful, as you can check whether the task was executed successfully and modify it if there were any errors.
Crontab Permissions
While you and all other system users can have their own crontab files, your ability to access and edit them can be restricted by your system admin, so stay in their good graces at all times! If your admin has listed your name in the “cron.allow” file, you can go ahead and create your very first cron job.
On the other hand, if you’ve been naughty and your name is in the “cron.deny” file, it might be time for a friendly chat with your system admin over a cup of coffee.
Cron Job Syntax
I hope you like to code, as it’s time to put the theories you’ve learned so far into practice! I appreciate curious people, so if you’ve racking your brain wondering what to do once you’ve opened your crontab file, keep calm; Cron job syntax is here.
Basic Structure
A cron job has five fields to schedule tasks:
- Minute (0-59)
- Hour (0-23)
- Day of Month (1-31)
- Month (1-12)
- Day of Week (0-7, where both 0 and 7 represent Sunday)
There’s no better way for me to explain these fields than by using an example
Example: 0 0 12 10 6. This may seem like binary code, but if you analyze the cron job, you’ll see that it’s designed to run a particular command (undefined for simplicity) at 12 AM on October 12. And the day happens to be a Saturday!
Understanding Time Fields:
I know I’ve covered the basic structure of these time fields, but I’m not done just yet. There are some special characters that add more flavor to cron jobs. For example, if you want to run a particular command at 12 AM every Saturday, you’ll need to replace the Day of Month and Month time fields with the “*” special character. Let’s explore special characters in more detail.
Special characters:
- * (wildcard): For more context, “*” means every possible value. So if I replace the Day of Month and Month fields in the above example with “*”, the command will run at 12 AM every Saturday.
- , (list of values): If you want to run the command on multiple days of the week, you can use “,” to specify multiple values. For example, if you use “1,3,6” in the Day of Week field, the command will run at 12 AM on Monday, Wednesday, and Saturday.
- – (range of values): You can use “-” to indicate a range of values, like running a cron job for a specific range of dates.
- / (step values): Now this one’s pretty cool, as it specifies increments. For instance, if you want to run a command every five minutes, you can use “*/5”. You may have noticed I used “*” in the syntax. I’ll leave it to you to guess why!
Some other popular special characters include “?” (question mark), “L” (last), and “W” (weekday).
Common Cron Job Examples
You may be itching to know how you can use cron jobs. Without going into depth (I’ll take the plunge in the following section), you can use cron jobs for tasks like daily backups, server log rotation, clearing cache, database optimization, sending out weekly reports, updating system packages, and checking disk space.
Use Cases of Cron Jobs
You can use cron jobs for around 20 to 30 distinct use cases. Here are the top five, along with common syntax:
- Backups: You can use a cron job to automate database or system backups at regular intervals (nightly or weekly, for instance)
Example: “0 2 * * * /path/to/backup.sh”
- Maintenance Tasks: If you’re responsible for system maintenance, it’s time you learned cron job syntax! You can implement them to run periodic system maintenance tasks like log rotation, cache cleaning, and updates.
Example: “0 3 * * 0 /path/to/logrotate.sh”
- Monitoring and Alerts: Your system needs robust monitoring capabilities. I suggest you use cron jobs to automate server monitoring scripts and send email or SMS alerts in case of failures or specific conditions.
Example: “*/5 * * * * /path/to/monitor.sh”
- Data Processing: If you need a quick fix to run batch processes, such as data imports, report generation, or log parsing, cron jobs are the way to go.
Example: “30 1 * * * /path/to/data_import.sh”
- Web and API Monitoring: Your organization may run multiple websites. Did you know you can use cron jobs to check the health of websites or APIs and alert admins (like yourself, perhaps) if downtime or issues are detected? You do now.
Example: “*/10 * * * * /path/to/health_check.sh”
There’s a reason I haven’t expanded on each example — each command automates the execution of the particular shell script. If you know what the script does, you know what the cron job does. Simple as that.
Advanced Features and Options
The full cron job syntax to run a backup task at 12 AM every Saturday is “0 0 * * 6 /path/to/backup.sh.”
But do you really need to run it on a Saturday and at 12 AM specifically? It seems forced, right? If all you want to do is run the backup task weekly, regardless of the time (it’s a background operation anyway), you can simply use the special cron string @weekly.
This is what the syntax would look like: “@weekly /path/to/backup.sh.”
Easy as that. The command will run every Sunday at midnight. Here are some other advanced cron job features and options!
Special Strings
There are five other special cron strings I want you to learn about: @reboot, @hourly, @daily, @monthly, and @yearly (they’re pretty self-explanatory).
- @reboot: Runs the command as soon as the system starts up.
- @hourly: Runs the command at the beginning of each hour.
- @daily: Runs the command once daily, at midnight.
- @monthly: Runs the command on the first day of every month, at midnight.
- @yearly: Runs the command on January 1 each year, at midnight.
Let’s move on to some other advanced features and options.
Environment Variables
Have you customized your car? If car mods aren’t your thing, you can instead customize cron jobs using environment variables (that’s much cooler).
For example, if you’re on the go and want to receive the output of a cron job in your mailbox, you can use the MAILTO variable to specify your email address. Similarly, you can implement the PATH and SHELL variables to define a particular directory or shell to use when executing a cron job.
Redirecting Output
Typically, the output of a cron job is displayed in your terminal after execution. If you want to capture it in a log file, you can redirect the output to one using the “>” redirection operator.
If you have no interest in the output and want to avoid clutter (some of us just care about the job being done), you can use the special file “/dev/null” — it acts like a black hole in Unix and Unix-like systems.
Job Overlap Prevention
By default, cron jobs can overlap and run concurrently. However, this may lead to issues like resource conflicts, data corruption, increased load, and log clutter.
While it makes sense to run multiple cron jobs at the same time, you need to ensure they don’t conflict or interfere with each other.
This requires careful management, and if you want to be on the safer side, you can use locking mechanisms like the “flock” command line utility — it prevents cron jobs from overlapping if one job takes longer than expected to complete.
Common Issues With Cron Jobs
As with any programming language, once you get the hang of cron syntax, creating cron jobs becomes pretty straightforward. However, you must be careful when you’re creating a cron job — even a small syntax mistake could prevent it from running.
For example, if you forget to include a space between any of the time fields in a cron job command, it’ll fail. And that’s not the only issue you may encounter. Here are some other common issues with cron jobs:
PATH and Environment Variables
By default, the cron daemon runs in a limited environment. This means it may not include environment variables like PATH and other custom variables. If you want to change the environment for your cron jobs, you’ll need to specify these variables directly in your crontab file.
For example, to include the PATH variable in your crontab file, you would type: “PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”. Save and exit the terminal to activate the changes.
Permission Problems
If your cron job isn’t running, it’s possible the script isn’t marked as executable. You can easily check the permissions by using the “ls -l” command in the terminal. For example, if you run “ls -l /path/to/script.sh” and you see something like “-rw-r–r–” it means the script isn’t executable. You can change its permissions by running “chmod +x /path/to/script.sh”.
On the other hand, if you see something like “-rwxr-xr-x” the script is executable and the problem lies elsewhere.
Silent Failures
Your cron jobs may fail silently, meaning you might not receive an error message or notification if something goes wrong. You can easily avoid this by logging errors (using redirection) or sending output to your email (using the MAILTO environment variable). This approach should help you troubleshoot issues more effectively.
Misconfigured Time Fields
Configuring the time fields in cron job syntax is as easy as tying your shoelaces, so please don’t tangle things up. You should have the numbers and special characters clear in your mind when you’re creating a cron job.
For example, there are 60 possible values you can enter in the hour field. Please remember you can only enter values from 0 to 59 — 60 or higher won’t work. Always double-check your syntax!
Tools and Utilities for Managing Cron Jobs
I’m a big fan of the Marvel universe and would jump at any opportunity to gain superpowers. If I had to choose one, I’d pick the ability to fly. If you thought cron jobs were like the rad assistant you always wanted, just wait until I show you how to supercharge them with these tools and utilities. In other words, here’s how you can manage cron jobs with superhuman qualities.
Cron Helper Tools
If you have a hard time tying your shoelaces and prefer slip-ons, you can use the crontab.guru tool to help you with cron job syntax. For example, if you want to run a command every five minutes but are struggling with the syntax, simply open the website, type “every five minutes” in the text box, and copy and paste the corresponding cron expression into the terminal.
Another great resource for understanding cron job schedules is cronjob.org — check it out!
Graphical Interfaces for Cron
If you’re not a fan of the command line interface (CLI) and prefer a graphical interface for managing cron jobs, try tools like Webmin and Gnome Schedule.
Both tools make it easy for you to add, edit, and remove jobs through an intuitive interface. Other noteworthy mentions include KDE Task Scheduler, Cronopete, and EasyCron.
Still, I recommend mastering the ins and outs of the CLI, since it will make using Unix that much more effective.
Advanced Schedulers
Earlier, I mentioned the cron daemon only comes to life as soon as you switch on your system.
If you want to run a scheduled job even when your system is turned off (for example, when your laptop isn’t powered on around the clock), you can use an advanced scheduler like Anacron. Systemd timers are another solid alternative — they allow for more complex scheduling and provide greater control over the timing.
Best Practices for Working with Cron Jobs
The best practices for working with me are: embrace your sense of humor (I’m even up for dad jokes), be specific, give me feedback, and please don’t play loud music when I’m in the zone. Now that you know me better, here are some best practices for working with cron jobs:
- Use Descriptive Comments: Your colleagues may have a hard time understanding the cron jobs in your crontab file if you don’t include comments. It’s also for your own benefit. Just use the “#” symbol to start a comment.
- Set Up Logging: The silent treatment is never fun, so if you want to avoid the excruciating pain of silent cron job failures, redirect the output of cron jobs to log files or use the MAILTO variable to send error reports via email.
- Avoid Overloading the System: What do you think might happen if 20 people enter an elevator designed for 10? Be mindful of system resources when scheduling resource-intensive jobs, especially during peak hours.
- Test Cron Jobs Manually First: When creating cron jobs, run the command manually to ensure it works as expected before adding it to a crontab.
- Use Version Control for Crontab Files: If you have an important crontab file, consider storing it in version control systems like Git for easy tracking and rollback.
If you follow these best practices, you’ll make me proud. Be sure to mention to your boss or colleagues how I helped you ace cron jobs.
Debugging Cron Jobs
Once you’ve created your first cron job, you should take it for a test drive. Only a fool would hit the highway without testing. Even if you take all precautions, you may face unexpected errors. After all, it takes days of practice to master any skill (perfection is an illusion). You can consider this my penultimate lesson on cron jobs.
Testing with Simple Commands
Before executing a full-fledged cron job, you can use simple commands like “echo” or “touch” to verify whether the syntax is correct and it works as intended.
You can use “echo,” for example, to record a predefined message in a log file whenever your cron job runs. On the other hand, you can use “touch” to create a new file in a specified directory whenever your cron job runs.
Checking the Crontab File
If you want to review your list of cron jobs, simply enter the “crontab -l” command in your crontab file. This is helpful in many ways.
For example, if a particular job isn’t running as expected, reviewing the cron job list can help you identify any missing or misconfigured entries.
You can also spot overlapping schedules and address potential conflicts.
Verifying Execution Logs
If you prefer Debian or Ubuntu, you can find your cron job logs by running the command “grep CRON /var/log/syslog.” On the other hand, if you prefer operating systems (OSes) like CentOS or RHEL, run the command “cat /var/log/cron” to access your cron job logs.
When analyzing the logs, you should consider factors like the timestamp, job execution, errors, and user context.
Using cron.d for Fine-Grained Control
If you’re a system admin, listen up: the “/etc’/cron.d/” directory may just be your new best friend. By using this directory, you can separate cron jobs into individual files (which have the same syntax as cron jobs) and assign them to users who should run them.
Security Considerations for Cron Jobs
Do you know what separates a good assistant from a great one? Knowing they’ll have your back no matter what. Cron jobs can be a loyal assistant to you, provided you take all security considerations into account.
- Secure Scripts: Use the “chmod” command to ensure the scripts you run have appropriate file permissions and don’t expose sensitive data.
- Least Privilege Principle: Always run cron jobs with the minimum privileges required, avoiding the root user if possible. This will help you limit damage in case of a compromised script.
- Managing User Cron Access: If you’re the system admin, regularly audit user permissions and update the “cron.allow” and “cron.deny” files accordingly.
- Preventing Cron Abuse: Your crontab file can potentially be compromised if proper security measures aren’t in place, so regularly monitor for unauthorized or malicious cron jobs. Again, if you’re the system admin, periodically review user crontabs.
Please bear with me: I’m going to mention Donna again. Donna is a great, loyal assistant to Harvey. If you follow these security steps, cron jobs will truly be like a Donna to you.
Cron Job: Your Automated Task Scheduler
Can you imagine how easy your life could be if you had a Donna in your life? She could handle all the boring, tedious tasks you’d have to otherwise do yourself. I mean, do you really want to manually perform backup tasks every day?
Let cron jobs take care of it — you could have your very own Donna.
If you’re familiar with the command line interface and are good at Unix, learning cron job syntax will be a piece of cake for you. You’ve already mastered the basics, so start practicing with simple tasks, experiment with redirecting output and locking, and read the official documentation for a deeper understanding of cron jobs.
You’re ready, mate. Reach for the stars!