While cron is great, crontab is a little risky. It's better to create files in /etc/cron.d (or cron.hourly etc.). That way you can manage them separately, you can put them in a source control system (or package manager, or makefile, or ansible role), and you aren't at risk of accidentally breaking them with crontab and a typo.
Adrian Colley I tend to agree, but this is really just on overview of cron and crontab at the most basic, abstract level. The additions in cron.d are the same format wise so the skills are the same. But yes, anyone reading this should RTFM for your Linux/Unix/BSD distribution and see what is it's preferred method of handling cron jobs and following that recommendation.
While cron is great, crontab is a little risky. It's better to create files in /etc/cron.d (or cron.hourly etc.). That way you can manage them separately, you can put them in a source control system (or package manager, or makefile, or ansible role), and you aren't at risk of accidentally breaking them with crontab and a typo.
ReplyDeleteAdrian Colley I tend to agree, but this is really just on overview of cron and crontab at the most basic, abstract level. The additions in cron.d are the same format wise so the skills are the same.
ReplyDeleteBut yes, anyone reading this should RTFM for your Linux/Unix/BSD distribution and see what is it's preferred method of handling cron jobs and following that recommendation.