Date: Tue, 23 Jan 2001 20:01:59 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Greg Black <gjb@gbch.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: <3A6E2987.711B626@bellatlantic.net> References: <Pine.BSF.4.31.0101211916030.66595-100000@dt051n37.san.rr.com> <3A6CE98B.4EA9EB9B@bellatlantic.net> <nospam-3a6d1369100d7ff@maxim.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Black wrote: > > Sergey Babkin wrote: > > > 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 There were political reasons for that. The applications which were presumed to be stopped by some specific time were supported by the applications group. The backup process was supported by the systems/database administration group. The border time was a result of negotiations between these two groups. > You keep demanding technical arguments (which I think means > arguments about the content of the proposed changes) -- but the Largely, yes. But in addition to that I would like to hear, why would be wrong to modify the behavior if this behavior is changed within the DST change timeframe only. In fact, one of the reasons why I limited my patch to the 1 hour difference and changes at the hour limit only was to provide additional guarentees that the behavior outside the DST change time frame would not be touched. Another reason was to keep things simple for now and thus reduce the chances of bugs. > 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 This is a valid argument. However I don't see particularly much risk in this sort ot fix. Of course, rigorous testing would be a very good thing to do. Even though I provided the functional test cases, the additional black box tests would never hurt. > 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. My point is that they had reasons for doing that: the demands of the users. In the commercial world nobody would budge for bug fixes unless they have some important customers crying out loud. -SB 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?3A6E2987.711B626>