Date: Sun, 21 Jan 2001 19:58:26 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etccrontab) Message-ID: <3A6B85B2.3A10195C@bellatlantic.net> References: <200101212035.JAA19266@ducky.nz.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Langille wrote: > > On 21 Jan 2001, at 14:50, Sergey Babkin wrote: > > > Let me ask a simple question: Why ? What are the benefits of > > preserving the old behavior ? > > First, it's not "old" behaviour. It is existing behaviour. There is a > difference. Because that's what was discussed and agreed to. On this > list. I believe this is just a difference of terminology. It's common to name the existing behavior "old" and the changed one as "new". > > As far as I've watched this thread > > nobody had explained it. So could you please elaborate ? > > Nobody explained it to your satisfaction but you still committed it? Nobody explained it to my satisfaction why I should not commit it. There is a subtle difference between these statements. > > On the other hand I clearly see the benefits of avoiding loss > > or duplication of once-a-day (or even more rare) cron jobs. > > If some job is scheduled once a day (or even once a week or > > once a month) then it's probably a rather heavy job. So running > > two of them at once is not a good thing even if they would not > > mess up each other but just slow down the machine. Skipping > > such a job seems to me as an almost equally bad thing. > > (Yes, I'm speaking from my personal experience as sysadmin as well). > > People have asked for the existing behaviour because they want it. > POLA has already been explained. Other reasons have been explained. > I'm assuming you read what I read. For me POLA means that the cron jobs must not disappear into nothing or be duplicated. So it's quite subjective and referring to such vague ideas as POLA is not a very technical reference. > > > behaviour default. _Especially_ if you intend to MFC this, since > > > changing this behaviour in a minor release, without a way to have the > > > old behaviour, is almost certainly wrong. > > > > That's why I asked for comments. > > You have pointed out the PR (24494). Does any documentation exist > which describes how this change will affect existing systems? Details Yes. In this PR and in a more detailed form in the change to the cron man page. The PR contains my test cases as well. > of the options for invoking the proposed new behaviour? Such things > were marked as important during the discussions. It would be helpful to > be able to read these things now that it has been commited. [before > anyone suggestions, no, I'm not going to read the code to find out] It still can be backed out. And because of the objections I'm going to add an option to enable the changed behavior in any case. Would there be any objections to the option name "-s" (from dSt) ? "-d" seems to be a bad idea because people would confuse it with the debugging option which is named "-x" in cron. -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?3A6B85B2.3A10195C>