Author: mark_user

Introduction

Crontab stand for CRON table and it is the primary task scheduler for Linux. The CRON daemon runs every minute and checks each user’s crontab (and the system crontab) for scheduled jobs. CRON will auto start on reboot and record to syslog natively when a job runs. CRON will send “standard out” and “errors” to the scheduled user’s mail account at /var/spool/mail/user. By default, CRON uses the bash shell to execute commands.

There are two types of crontabs; user crontabs and system crontabs. The system wide CRONTAB jobs are stored in /etc/crontab. It is used to execute scripts that apply to the system change or all users. It requires an additional field in the crontab called a user field. This article will be focused on setting up a user’s crontab.

If your script runs successfully from the command line, but not when it is run as a CRONTAB job, it is because crontabs are executed by the user CRON. That user has limited rights and does not have the same environmental variables as a regular user. It is recommended to always use absolute paths for shell, commands, and scripts, in your crontab.

Understanding crontab

MIN HRS DOM MON DOW <Conditional Statement>  <Command> <Argument>
 0   8   *   *  tue [ `date +\%d` -le 7 ] && /bin/bash /home/user/script.sh >/dev/null 2>&1

Key Terms:

• Min = 0 to 59
• Hour = 0 to 23 (Hours are in Military time)
• Day of Month = 1 to 31
• Month = 1 to 12 or Jan, Feb, Mar
• Day of Week = 0 to 6 (0 is Sunday) or mon, tue, wed
• @reboot = run once after reboot

Pattern Matching:

• * = match everything
• Range = 0-4 or jan-jun
• List = 1,3,7,16 or mon,tue,wed
• Step Values = 0-23/2 = run the job every two hours for 24 hours.

File Locations:

• System file =/etc/crontab
• System jobs = /etc/cron.d/ (Location to store system scripts)
• System jobs = /etc/cron.daily (Location to store system scripts)
• System jobs = /etc/cron.weekly (Location to store system scripts)
• System jobs = /etc/cron.hourly (Location to store system scripts)
• User’s crontab (debian) = /var/spool/cron/crontabs/<user>. (DO NOT EDIT DIRECTLY)

Troubleshooting:

• Crontab Logs = /var/log/syslog (logs, i.e. did command run??)
• Crontab Job Results (debian) = /var/spool/mail/<user> (output and errors)
• Verify cron is running = sudo systemctl status cron (Is cron running ??)

List the current user’s crontab

crontab -l

Edit current user’s crontab

crontab -e

NOTE: Some documents say, after you save and install a new CRONTAB, you need to reload the CRON service by running “service cron reload”. But, other documents say you do not to perform this action.

Remove current user’s crontab

crontab -r

List another user’s crontab

sudo crontab -u user -l

Run a job at a specified time

NOTE: CRON uses military time, which is using hours 0 to 23.

HR MIN DOM MON DOW
* * * * * /bin/bash /home/user/script.sh (every minute of everyday)
0 0 * * * /bin/bash /home/user/script.sh (midnight everyday)
*/5 * * * * /bin/bash /home/user/script.sh (every 5 minutes)
0 17 * * * /bin/bash /home/user.script.sh (5pm everyday)
0 7,19 * * * /bin/bash /home/user/script.sh (7am & 7pm everyday)
0 7 2-4 * * /bin/bash /home/user/script.sh (7am, 2nd,3rd,4th of the month)
0 21 * * 1-5 /bin/bash /root/test.sh  (9pm, Monday thru Friday)
0 7 * * tue [ $(date +\%d) -le 7 ] && /bin/bash /root/script.sh (7am,1st Tue of month)

Potential syntax errors

0 7 1 * Mon /bin/bash /home/user/script.sh

Be careful when writing cron jobs. For the day of week and day of month fields, crontab should be interpreted as AND statements. The command will run when either field matches the current time! This example would not run a script on the first Monday of the month. Rather, this job runs on the first day of the month and every Monday.

*/35 * * * * /bin/bash /home/user/script.sh

Skip values can only operate within the time period they´re attached to. The above will not execute every 35 minutes. Rather, it will execute at 0 minutes and 35 minutes each hour.

Start a program on server reboot

@reboot /usr/bin/perl -w /data/nfsen/bin/nfsen start 

“/usr/bin/perl -w” mean to enable and print warning messages.

Run a script and email the results

30 6 * * * /usr/bin/python3 /root/script.py | mail -s "Results" user@company.com

Send stdout&err to syslog w tag “ossec”

30 7 * * * /bin/bash /home/max/backup.sh 2>&1 | /usr/bin/logger -t ossec

Redirect screen & error output

Screen output and errors are recorded in the user’s mailbox at /var/spool/mail/<user>. When scripts run overnight, output to the screen (stdout) is not needed. It is common to send standard out to /dev/null and errors to a custom log file. You will need to ensure that the log file does not grow out of control.

2>&1 means to send any errors to the same location as standard out. Order matters! you can not send errors to location that does not exist. Be sure to identify the location of the screen output first.

>/dev/null (delete std out)
>/dev/null 2>&1 (delete std out & errors)
>/dev/null 2>>/home/user/err.log (del std out, append err to log)
>/dev/null 2>>/var/log/syslog (del std out, append err to syslog)
>>/home/user/file.log 2>&1 (append std out & err to a custom log)

References

https://krisjordan.com/blog/2013/11/04/timesaving-crontab-tips

https://www.generateit.net/cron-job/