Date: Tue, 23 Jan 2001 15:15:21 +1000 From: Greg Black <gjb@gbch.net> To: Sergey Babkin <babkin@bellatlantic.net> Cc: Doug Barton <DougB@gorean.org>, cvs-committers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h Message-ID: <nospam-3a6d1369100d7ff@maxim.gbch.net> In-Reply-To: <3A6CE98B.4EA9EB9B@bellatlantic.net> of Mon, 22 Jan 2001 21:16:43 EST References: <Pine.BSF.4.31.0101211916030.66595-100000@dt051n37.san.rr.com> <3A6CE98B.4EA9EB9B@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sergey Babkin wrote: > To mention it from the start, I've backed out my changes. Thank you. > There are other things which may not allow a job to finish in > a predefined time slot. For example, other operations going on > and consuming CPU, disk or network bandwidth. So presuming > that a job would finish by some time is inherently unsafe. > The safe way is to put both jobs sequentially into one script > and run this one script from cron. Remember that for later. > Time critical jobs should be avoided at all, by including all the > dependent jobs into one script and running only this script > from cron. And remember that while you read this: > I can give you one example from my past experience: a nightly cold > backup of a database which takes a long time, must be started after > all the day's work would be complete, and finish by 7:30AM the next > morning. The time of backup depends on the amount of change logs > generated during the day, so to be safe it should be started as > early as possible. Well, eventually we got the day's close > processing to complete by 12:50 and scheduled the job there. > But the fact that two hours of time are unusable for starting > any jobs is not a particularly exciting one nor fun to discover. This is an absurd claim, especially in the light of what you said earlier (quoted above). If the backup depends on the processing of something else, then the script that starts the other processing should run the backup at the end, and issues of DST are completely irrelevant. This has always been the case, and still is. You keep demanding technical arguments (which I think means arguments about the content of the proposed changes) -- but the matter of concern to me is /not/ that at all, it's whether there is any need for potentially breaking an important utility which has known behaviour to "solve" things that don't need and are not suited to technical solutions, no matter who else might think that is the way to go. Arguing that commercial Unix vendors have decided to meet the lowest common denominator by changing cron is not a case for FreeBSD to go down the same road. > > > > I made the additional point that the options should be command line > > > > options, instead of environment variables as someone else suggested. > > > > > > And I made the additional point that practically all the commercial > > > Unixes do support intelligent handling of DST. Being different > > > from them makes no good and is a lot of inconvenience. > > > > If you want to offer the option of making cron think for the user > > instead of following traditional behavior then it should be offered as a > > command line option, defaulting to off. Period. "We're not like everyone > > else" is not a compelling argument here. > > This sort of arguments is largely responsible for why Unix had > branched in so many incompatible ways. The NIH syndrome is not > the most productive approach. A certain TLA once came out with their own Unix (known by another TLA) and I had the joy of working with beta versions of this OS. Thousands of things just didn't work, including dozens of awk scripts. It turned out that the company had "audited" the awk code and "fixed" it to comply with their in-house coding standards. Just because other people do something is not of itself a compelling argument to follow suit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?nospam-3a6d1369100d7ff>