-ray wrote:
The problem with /etc/cron.daily is everything kicks off at the same time.
I often have large jobs that i don't want starting at the same time. Also,
I haven't tested this, but RHEL5 uses ISC cron 4.1 and apparently
discontinues using symlinks. From the man page:
/etc/cron.daily and the like do not run everything at once. They run
them in file order, eg alphabetically unless you prepend numbers to
each name in the directory so jobs that need to run a particular order
can be controlled.
Of course if you want to spread the jobs throughout an hour period, you
need to do something different.
---
CAVEATS
In this version of cron , without the -p option, /etc/crontab must
not be writable by any user other than root, no crontab files may be
links, or linked to by any other file, and no crontab files may be
executable, or be writable by any user other than their owner.
---
>From a management perspective, user crontabs would be the most consistent
across Unix flavors. Commercial systems like Solaris and AIX only have
user crontabs, and have none of the /etc/cron* stuff. But you
specifically said Linux. :) And the root user crontab has the same issues
as /etc/crontab.
Although I personally don't use it a lot, I would say /etc/cron.d
provides the best balance of manageability and flexibility. If writing a
new policy, I would probably go with /etc/cron.d.
ray
On Tue, 8 Jan 2008, Dustin Puryear wrote:
So what do you do when you need to run a job as a non-root user? Do you
just modify /etc/crontab?
--
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
Identity Management, LDAP, and Linux Integration
Adam Melancon wrote:
Never really use the users crontab.
Put custom timed stuff in /etc/cron.d/ (stuff that runs every 5min like MRTG)
If it's something that runs daily, it always goes in /etc/cron.daily/
If it's something that runs hourly, it always goes in /etc/cron.hourly/
This is what I usually follow.
On Jan 8, 2008 8:54 PM, Dustin Puryear <[EMAIL PROTECTED]> 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
Identity Management, LDAP, and Linux Integration
_______________________________________________
General mailing list
[email protected]
http://mail.brlug.net/mailman/listinfo/general_brlug.net
_______________________________________________
General mailing list
[email protected]
http://mail.brlug.net/mailman/listinfo/general_brlug.net
|
