[26722] in Source-Commits
Re: /svn/athena r25696 - in trunk/athena/bin/desync: . debian
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Tue Aug 7 19:34:17 2012
Message-Id: <201208072334.q77NYFdo010928@outgoing.mit.edu>
To: Jonathan Reed <jdreed@MIT.EDU>
cc: Jonathon Weiss <jweiss@MIT.EDU>, source-commits@MIT.EDU
In-reply-to: <1BAC3795-7225-4B52-B01C-6C6888FA1C40@mit.edu>
Date: Tue, 07 Aug 2012 19:34:14 -0400
From: Jonathon Weiss <jweiss@MIT.EDU>
Jonathan Reed <jdreed@MIT.EDU> wrote:
>
> 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.
OK, I assume you'll apply a patch soon.
> > 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.
I agree in hours mod 24, since "desync -c 23 120" seems like a plausible
use case to run something between 11pm and 1am. However, I still think
the check is a good idea, as someone who specifies a value > 1440 is
likely confused, and spitting out an error is arguably better than
doning something they don't expect. (though any interval containing
exactly an integer number of half-hours will be 0 mod 24 and generate an
error for that reason, so the most common cases will be spit out for the
wrong reasons as is :-)
Jonathon
