Date: Wed, 6 Nov 2013 20:43:43 -0800 From: Lyndon Nerenberg <lyndon@orthanc.ca> To: Kimmo Paasiala <kpaasial@gmail.com> Cc: FreeBSD current <freebsd-current@freebsd.org> Subject: Re: cron(8) improvement Message-ID: <D260751E-85D2-4591-88E0-5EFE1821D532@orthanc.ca> In-Reply-To: <CA%2B7WWSdFFk4npy0=TOWO=6RApv5-wuJASHhE87eUf52DjQrxjw@mail.gmail.com> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <CA%2B7WWSdFFk4npy0=TOWO=6RApv5-wuJASHhE87eUf52DjQrxjw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala <kpaasial@gmail.com> wrote: > What's wrong with using the existing tools for achieving the same > effect? Periodic can be adapted to do exactly what you're describing > as noted above by adding an hourly (even minutely? :D ) periodic run. Periodic is geared towards periodic system maintenance tasks. Once per = day, once per week, once per month. It doesn't deal with tasks that = need to be fired off at arbitrary intervals. As you say, it could be adapted to run things with per-minute = granularity, but it wouldn't scale well. For per-minute granularity you = would have to fire off a periodic run every minute. That's five times = the rate that atrun(8) kicks off at. That's a lot of overhead for = small, embedded, or power constrained systems. And to get the = time-granularity cron has, you would have to re-implement cron(8)s = dispatch control as a set of shell functions. That's just silly. --lyndon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D260751E-85D2-4591-88E0-5EFE1821D532>