Cron

crond - daemon to execute scheduled commands.

crontab - Used to schedule repetitive tasks/commands. *must be root*

Good info:

How to use crontab

/etc/crontab - User specific cron jobs
/var/log/cron - Logs (You can check this to see if the cronjob is running)

For details see man 4 crontabs

Example of job definition:

.---------------- minute (0 - 59)
|  .------------- hour (0 - 23)
|  |  .---------- day of month (1 - 31)
|  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
|  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
|  |  |  |  |
*  *  *  *  * user-name  command to be executed

EXAMPLE CRONTAB:

At every 12th hour and 30 min, it will run that command.
If all categories were "*" then it will run the command every minute.

MIN    HOUR    DOM     MON     DOW     CMD
30       12       *       *       *       /home/ardika/Scripts/first.sh

0 * * * *	every hour
*/15 * * * *	every 15 mins
0 */2 * * *	every 2 hours
0 0 * * 0	every Sunday midnight
@reboot	every reboot

Define user, only need this is you are ROOT.

crontab -u

To see what crontabs are currently running.

sudo crontab -l                  
sudo crontab -u ardika -l

To edit the list of cronjobs you can run.

sudo crontab -e        
sudo crontab -u ardika -e

How I Configured Automated Certificate Renewal

Instructions: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html#letsencrypt

Open /etc/crontab in a text editor and add a line similar to the following.

39 1,13 * * * root certbot renew --no-self-upgrade

Schedules a command to be run at 01:39 and 13:39 every day. The selected values are arbitrary, but the Certbot developers suggest running the command at least twice daily. This guarantees that any certificate found to be compromised is promptly revoked and replaced.
root - The command runs with root permissions.
certbot renew --no-self-upgrade - The command to be run. The renew subcommand causes Certbot to check any previously obtained certificates and to renew those that are approaching expiration. The --no-self-upgrade flag prevents Certbot from upgrading itself without your intervention.

Restart the cron daemon.

systemctl restart crond

Misc. Notes

Your scheduled cron jobs also run as your main user, but they don't use the PATH settings that your user has. So, if you are running like aws cli from a bash script in your cron, be sure to check PATH: example:

$ cat /etc/cron.d/popularity-contest 
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
20 0 * * *   root    test -x /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity- contest --crond

Troubleshooting Cron Jobs

https://serverfault.com/questions/449651/why-is-my-crontab-not-working-and-how-can-i-troubleshoot-it

Education about cron:
Every user on a system may have their own crontab file. The location of the root and user crontab files are system dependant but they are generally below /var/spool/cron.

There is a system-wide /etc/crontab file, the /etc/cron.d directory may contain crontab fragments which are also read and actioned by cron. Some Linux distributions (eg, Red Hat) also have /etc/cron.{hourly,daily,weekly,monthly} which are directories, scripts inside which will be executed every hour/day/week/month, with root privilege.

root can always use the crontab command; regular users may or may not be granted access. When you edit the crontab file with the command crontab -e and save it, crond checks it for basic validity but does not guarantee your crontab file is correctly formed. There is a file called cron.deny which will specify which users cannot use cron. The cron.deny file location is system dependent and can be deleted which will allow all users to use cron.

If the computer is not powered on or crond daemon is not running, and the date/time for a command to run has passed, crond will not catchup and run past queries.