[26721] in Source-Commits
Re: /svn/athena r25696 - in trunk/athena/bin/desync: . debian
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Tue Aug 7 18:04:59 2012
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <201208072109.q77L95sd025717@outgoing.mit.edu>
Date: Tue, 7 Aug 2012 18:04:54 -0400
Cc: source-commits@MIT.EDU
Message-Id: <1BAC3795-7225-4B52-B01C-6C6888FA1C40@mit.edu>
To: Jonathon Weiss <jweiss@MIT.EDU>
Content-Transfer-Encoding: 8bit
On Aug 7, 2012, at 5:09 PM, Jonathon Weiss wrote:
> You've changed the semantics for "range". In crontab mode it's minutes,
> but in the original mode it is seconds. It probably doesn't make sense
> to specify it in seconds for crontab mode, but that certainly needs to
> be documented. Hopefully it won't be too confusing for it to be
> different in the two cases.
Yes, this should be documented.
> Pulling these two together, there's the related problem that if you
> don't specify the range or additional arguments, but you do specify
> crontab mode, you get a default of 3600 *minutes*, which doesn't make
> sense.
>
> I'd also advocate for a check in crontab mode that interval is <= 1440
> (one day), since the code outputs a cron entry that will be run daily.
> (Being flexible enough to output something that isn't necessarily run
> daily may not be of enough value to actually code, but I could see use
> cases for it.)
I originally had this check in there, but removed it on the grounds that what we want to check is not that range <= 1440, but rather that the end result is something sane. (e.g. desync -c 23 1439 will still have unexpected behavior). So instead, we always take hours mod 24. That too should be documented. If you think it's worthwhile re-adding the check, I can do so.
-Jon
