[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SAGE] crontabs vs /etc/cron.[daily,hourly,*] vs. /etc/cron.d/

I believe that the location of cron entries should be dependent on the entity that is managing those cron entries.
I prefer to see system-related cron entries in /etc/cron.d or /etc/cron.[daily|hourly|...] - for example, things that are managed by a packaging facility like yum that are installed by the sysadmins.
I prefer to see user or custom application cron entries in user crontabs, managed by the user or applications team, but there are also packages that reduce or eliminate the need for user crontabs for applications - and also provide more functionality like monitoring, dependency control, and coordination with applications deployment (e.g., Orsyp's Dollar Universe, Autosys,...). These packages can give centralised control and visibility of scheduled/batch processes while still allowing non-root users to control their jobs. 

- Richard

Gary Richardson wrote:
I second /etc/cron.d -- it's explicit and easy to manage. I like to have a cron.d file for each application that users crontabs so it's easier to keep track.
On Jan 8, 2008 7:24 PM, Mason Turner < mason@xxxxxxx <mailto:mason@xxxxxxx>> wrote: 

    I am a big fan of /etc/cron.d, mostly because it is a lot cleaner to
    manage entire files (versus edits) with configuration management
    tools.

    -- Mason Turner

    On Jan 8, 2008, at 9:53 PM, Dustin Puryear <dustin@xxxxxxxxxxxxxx
    <mailto:dustin@xxxxxxxxxxxxxx>>
    wrote:

    > So, we have an internal debate at Puryear IT about how to best setup
    > cronjobs. First, let's assume Linux here. Every UNIX flavor has some
    > unique trick it likes to use, but Linux is a good example of
    several
    > ways to do cronjobs.
    >
    > So, with most Linux installs, you have these options:
    >
    > 1. normal use of crontabs
    > 2. creating a crontab-like entry in a file in /etc/cron.d/
    > 3. creating symlinks to your scripts in /etc/cron.hourly/,
    > /etc/cron.daily/, etc. (I'll just say /etc/cron.daily to be short.)
    > 4. /etc/crontab for the root user being able to run cron jobs as any
    > user, unlike /etc/cron.d/ and /etc/cron.daily/.
    >
    > The question here isn't one of technical correctness (they are all
    > correct), but one of consistency both internally and, potentially,
    > with
    > other people messing with cronjobs on the same box.
    >
    > The debate started when I logged into a server and didn't see
    our jobs
    > in root's crontab or as symlink under /etc/cron.daily/. They were in
    > /etc/cron.d/. Fine. Except I never do that. I usually use a user's
    > crontab or /etc/cron.daily/. So, immediately, we have a internal
    > consistency issue, which could, conceivably, cause me to create a
    > duplicate cronjob. (Let's ignore documentation and change
    management.)
    >
    > The problem I have with /etc/cron.d/ is that most people DON'T
    USE IT.
    > Sure, system scripts that come with the distro often do, but,
    really,
    > how many sysadmins create their cronjobs there? Not many in my
    > experience. Yet, there is a certain cleanness to /etc/cron.d/. :)
    >
    > /etc/crontab has the unique benefit of letting centralize your
    > cronjobs,
    > but then you have a single file that everyone has to muck with.
    Yuck.
    > Oh, and trouble..
    >
    > So, what are your thoughts? How do you handle this?
    >
    > --
    > Puryear Information Technology, LLC
    > Baton Rouge, LA * 225-706-8414
    > http://www.puryear-it.com
    >
    > Author, "Best Practices for Managing Linux and UNIX Servers"
    >  http://www.puryear-it.com/pubs/linux-unix-best-practices
    <http://www.puryear-it.com/pubs/linux-unix-best-practices>
    >
    > Identity Management, LDAP, and Linux Integration