Cron is the system scheduler on Unix/Linux/Mac operating systems. The crontab is the schedule of actions that the machine must keep. There are two types of crontabs in place on most systems: user crontabs and the system crontab.
Contents
Avoid User Crons
System administrators who manage servers and services should emphasize system crons over user crons. User crontabs are generally found under /var/spool/cron/crontabs and should be avoided in the context of managing cron for a server. They are intended for when a system is a multi-user system where individual users all may have regular maintenance scripts and commands that they manage themselves.
System Cron Standard
example.com servers should all be using system crontabs to manage the functionality that the server is responsible for. Specifically, this includes the files /etc/crontab, the files under /etc/cron.d/, and usually, the cron.hourly, cron.daily, cron.monthly folders. All example.com-specific crontab entries should be made to the file /etc/cron.d/example.com or /etc/cron.d/example.com-something. If this file is not present, it should be created.
How to edit crontabs
- Use a Text Editor to create/edit
/etc/cron.d/example.comand add entries for new schedule jobs. - Send notification to the "Core Tech" about the adjustment.
- Comment Make sure your crontab entries include generous comments about what it does, when it does it etc, when it was implemented or last changed etc. Do not rely on the user's ability to read (cryptic) cron systax! nor force the user to inspect the contents of each script. Do point to reference sources like wiki or support URLs for detailed information. Complex scripts should be written independently, tested and saved to /root/bin where they can be easily called from cron.
User crons
Using user crontabs is discouraged for servers, but common in personal workstations or development environments
General crontab hints
- Use
crontab -lto list the crontab for the current user - Use
crontab -eto edit the crontab for the current user man crontabcan provide a lot more information.
One-time Jobs
You can certainly use cron to run one-time jobs, but that would be more effort than it's worth, since cron is designed for repeating jobs. The at command is the correct tool for this job.
Using the at command, you can specify a job to be run at some time in the future. The most common thing I do with at is schedule a reboot. Of course if you just want to reboot the machine at 10pm, you can do /sbin/shutdown -r 22:00 "rebooting at 10:00 P.M." & Do this in a screen session to ensure that the current shell does not need to be intact, but I think backgrounding the process with & takes care of that (depending on your shell environment). Anyway, the shutdown command is not as flexible with date and time arguments as the at command. With at, you can specify at 8am tomorrow. Invoking this command launches an interactive shell which you then enter the command to be executed. E.g. shutdown -r now. Finally, you exit the interactive shell with Ctrl+d. atq will list the jobs in the queue. at -c 1 will 'cat' (display) details of job 1 atrm 1 will remove job #1 from the queue.
Since at reads from STDIN, you can just pipe the command to it rather than using the interactive shell: echo "ls -al" | at now + 1 minute Note that since at runs non-interactively with a different shell, you won't actually see the results of the 'ls' command.
echo "shutdown -r now" | at 8am tomorrow
echo "shutdown -r now" | at midnight 2017-02-25
# show the queue
atq
# show details of job 1
at -c 1
# cancel / remove job 1
atrm 1