tag:blogger.com,1999:blog-7997313029981170997.post249512799651751149..comments2010-01-09T17:36:19.765-05:00Jon Jensenhttp://www.blogger.com/profile/18273388885281263476noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-7997313029981170997.post-43733895223611509532009-10-07T06:37:46.978-04:002009-10-07T06:37:46.978-04:00Greg, this is a very useful article. I&#39;ve used cron for a while and have learned most of the stuff you mentioned through trial-and-error. I don&#39;t use full paths for binaries that are in the cron daemon&#39;s path. When using cron, it&#39;s always good to determine the environment used by cron (* * * * * env &gt; some-file), given the different crons out there. I came across your blog while checking out if people version control their crontab files, as I believe it&#39;s a good practice and I&#39;m introducing a structured way to do so (using SVN) within my Organization. Glad to see version control listed right at the top!Gavin Saturhttp://itsupport.mrkips.comnoreply@blogger.comtag:blogger.com,1999:blog-7997313029981170997.post-13978112850588917762008-12-10T16:26:00.000-05:002008-12-10T16:26:00.000-05:00&gt; so what is the advantage of hardcoding the path of /usr/bin/psql<BR/><BR/>I&#39;ve been burned too many times with having to deal with multiple instances of the psql binary to not hardcode it these days. I agree that things like /bin/cp are overkill though. The noise of long paths is another reason I throw such things in ENVs at the top of the file.<BR/><BR/>&gt; I have to disagree with the suggestion that one should document the run times for each job. On several occasions I&#39;ve had to track down crazy problems caused by the comment not matching up with the actual job specification, and others were tricked by it too<BR/><BR/>I still would rather have it spelled out explicitly. Not only does it make it easier to read for non-cron aware people, but it helps you to spot other people&#39;s mistakes. Forcing them to document what they *think* the line is doing is a good way to catch problems. I consider it a checksum. Any mismatch means they entered the specification wrong, cut-n-pasted the wrong entry, or just documented things incorrectly. Whatever the cause, it&#39;s a red flag that should be followed up on. I think it&#39;s worth the danger of readers relying solely on the documentation.<BR/><BR/>&gt; Do you have any complaints about the now quite common anacron, that lead to your liking fcron for rescheduling jobs?<BR/><BR/>I don&#39;t like that anacron is not a user-level tool. This makes fcron far superior in my book, as it seems to be a superset of both cron and anacron. Plus, it has some neat bells and whistles like &#39;serial&#39; and &#39;erroronlymail&#39;. Truthfully, I rarely use either one, but I suppose I should simply start promoting fcron rather than making a wishlist for cron. :) Thanks for the reply!Greg Sabino Mullanehttp://www.blogger.com/profile/01284672712225991979noreply@blogger.comtag:blogger.com,1999:blog-7997313029981170997.post-82111764695944955382008-12-08T20:51:00.000-05:002008-12-08T20:51:00.000-05:00Those are excellent notes, Greg.<BR/><BR/>I heartily second the advice to test a cronjob a few minutes into the future -- it's a real waste to only find out the next day that the nightly job didn't run because cron's environment was different than your own shell, causing a failure.<BR/><BR/>I've found with vixie-cron, at least, that you have to schedule your test job at least 2 minutes in the future, or it won't run. This is apparently because cron reads jobs one minute in advance, so you need an extra padding minute to get your job in in time.<BR/><BR/>Speaking of environment, cron usually runs with a fixed PATH set in /etc/crontab, so what is the advantage of hardcoding the path of /usr/bin/psql vs. /bin/cp? Either one could show up somewhere else in the path, but at least on RHEL 5 both are safe without a full path because PATH is simply:<BR/><BR/>/sbin:/bin:/usr/sbin:/usr/bin<BR/><BR/>So it seems unless you know your program will be outside that path, there's no particular need to specify, is there? It doesn't hurt, but sometimes the extra noise makes the whole crontab harder to read.<BR/><BR/>On a similar note, it's helpful to use the fact that cron jobs run cd'd into the user's home directory, so no reason to specify a full path /home/$USER/bin/whatever when bin/whatever will do nicely and survive home directory moves as well.<BR/><BR/>I have to disagree with the suggestion that one should document the run times for each job. On several occasions I've had to track down crazy problems caused by the comment not matching up with the actual job specification, and others were tricked by it too. I think documenting the implementation (rather than the intent) falls into the category of "don't repeat yourself", and leads to "wrong documentation is worse than no documentation". I now just recommend anyone review "man 5 crontab" who doesn't know crontab syntax.<BR/><BR/>Do you have any complaints about the now quite common anacron, that lead to your liking fcron for rescheduling jobs?Jon Jensenhttp://www.blogger.com/profile/18273388885281263476noreply@blogger.com