This line runs my self-written Bash shell script, rsbu, that backs up all my systems. This line in my /etc/crontab runs a script that performs backups for my systems. 01 01 * * * /usr/local/bin/rsbu -vbd1 /usr/local/bin/rsbu -vbd2 There are several comment lines in the example above that detail the syntax required to define a cron job. I'll break those commands down, then add a few more to show you some more advanced capabilities of crontab files. Even though the path is set here, I always prepend the fully qualified path to each executable. The third line sets up the PATH for the environment. These emails can provide the status of the cron job (backups, updates, etc.) and consist of the output you would see if you ran the program manually from the command line. The MAILTO variable sets the email address where cron job results will be sent. The SHELL variable specifies the shell to use when commands are executed. The environment must be set to whatever is necessary for a given user because cron does not provide an environment of any kind.
Cron job example code#
The first three lines in the code above set up a default environment. The crontab command is used to view or edit the cron files. # Perform monthly updates on the first of the month
# Set the hardware clock to keep it in sync with the more accurate system clock # backup using the rsbu program to the internal 4TB HDD and then 4TB externalĠ1 01 * * * /usr/local/bin/rsbu -vbd1 /usr/local/bin/rsbu -vbd2 # * * * * * user-name command to be executed day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat I added the job definition example below to my own cron files, just as a quick reference, so I know what the various parts of a command mean. New cron files are empty, so commands must be added from scratch. The crontab command uses Vi as its underlying editor, because Vi is always present (on even the most basic of installations). Using the crontab command not only allows you to edit the command, it also restarts the crond daemon when you save and exit the editor. I strongly recommend that you not use a standard editor (such as Vi, Vim, Emacs, Nano, or any of the many other editors that are available). The cron utility runs based on commands specified in a cron table ( crontab). Each user, including root, can have a cron file. These files don't exist by default, but can be created in the /var/spool/cron directory using the crontab -e command that's also used to edit a cron file (see the script below). The /etc/anacrontab is a special case that will be covered later in this article. The individual user cron files are located in /var/spool/cron, and system services and applications generally add cron job files in the /etc/cron.d directory. The contents of these files define cron jobs that are to be run at various intervals. The cron service checks for files in the /var/spool/cron and /etc/cron.d directories and the /etc/anacrontab file. The crond daemon is the background service that enables cron functionality. Many system processes and services, like Logwatch, logrotate, and Rootkit Hunter, use the cron service to schedule tasks and run programs every day.It contains information, such as disk usage, that should be current in order to be useful. I also have a Bash program I run early every morning that creates a new "message of the day" (MOTD) on each computer.
I use cron to set the hardware time based on the system time. While NTP sets the system time, it does not set the hardware time, which can drift.
Cron job example how to#
In this article, I'll introduce the cron service and how to use it. The cron service can schedule tasks on a repetitive basis, such as daily, weekly, or monthly. The at service specifies a one-time task that runs at a certain time. The cron and at services enable sysadmins to schedule tasks to run at a specific time in the future. Instead, I use two service utilities that allow me to run commands, programs, and tasks at predetermined times. And I don't want to have to get up at oh-dark-hundred to start a backup or major update. I have no time to spare in the evenings to run commands and scripts that have to operate during off-hours. For example, some tasks (including regularly recurring tasks) need to run overnight or on weekends, when no one is expected to be using computer resources. One of the challenges (among the many advantages) of being a sysadmin is running tasks when you'd rather be sleeping.
0 kommentar(er)
