[Novalug] is this obvious (to everyone but me?)

cerberus novalug@ginch.org
Sat Apr 4 17:19:47 EDT 2015


> 
> On Apr 4, 2015, at 12:48 PM, Jon LaBadie via Novalug <novalug@firemountain.net> wrote:
> 
>> /etc/cron.* directories are typically used for system
> activities.  As Greg noted, they are run as root.  

I need to chime in here. I feel that the (anacron) /etc/cron.d/ is an epic leap forward in cron job management for a number of reasons.  

0) When cron was invented, all evolution of computing ended, IMNSHO. A tool that allows me to tell a computer to do something over and over again without human interraction?  Perfection.  I don’t really care about anyone elses opinion on this, so don’t attempt to correct me. :)

1) A job run from this directory can be run as any user.  "* * * * * root /path/to/command” is the norm found in here, but “* * * * * novalug /path/to/command” is also totally valid.  

2) A job is discrete. It can live defined in /etc/cron.d/all_my_jobs_live_in_texas along with several dozen other jobs, each running as different users, OR it can live in a file by itself in /etc/cron.d/my_job_and_easy_to_maintain.  

This distinction lends itself to being easily managed via some sort of system, be it rcs, chef, puppet, svn, or rsync.  It also makes it much easier to tie a cron job to some other software deployment, inlcuding future updates.  If you’ve ever had the “luxury” of attempting to manage many cron entries in a /var/spool/cron crontab file, you know why  this is important.

3) In addition to /etc/cron.d/ (the “anything goes” space), /etc/cron.daily, /etc/cron.hourly, et al also exist. Drop an entry in here and it just executes when you’d expect it based on the name of the directory.  The number of screwups I’ve seen where folks didn’t know how to set the beginning 5 fields correctly is astonishing.

4) Job definitions that include env variables like MAILTO, SHELL, and others, are much MUCH easier to manage when each job has its own file.  

5) For users that need to mess with cronjobs manually via crontab -e, let ‘em.  When they accidentially delete jobs they didn’t mean to, they get to suck it up and deal with the mistake.  After they screw up, they might be more amenable to migrating to /etc/cron.d/.  

When it comes to admins managing many machines worth of crontabs centrally, even for non system activities, /etc/cron.d/ wins hands down.

-dave

--
Dave Paper                          

"The trouble with quotes on the Internet is you never know if they are genuine.” —Abraham Lincoln





More information about the Novalug mailing list