From owner-freebsd-current@FreeBSD.ORG Thu Nov 7 04:44:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CC9278F3 for ; Thu, 7 Nov 2013 04:44:17 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200::42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A2A752986 for ; Thu, 7 Nov 2013 04:44:17 +0000 (UTC) Received: from [192.168.42.6] (d66-183-220-167.bchsia.telus.net [66.183.220.167] (may be forged)) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id rA74iDOp049326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Nov 2013 20:44:15 -0800 (PST) (envelope-from lyndon@orthanc.ca) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: cron(8) improvement From: Lyndon Nerenberg In-Reply-To: Date: Wed, 6 Nov 2013 20:43:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> To: Kimmo Paasiala X-Mailer: Apple Mail (2.1816) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 04:44:17 -0000 On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala 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