From owner-freebsd-current@FreeBSD.ORG Sun Nov 10 01:55:41 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 7D1BB80D for ; Sun, 10 Nov 2013 01:55:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 372B42EE4 for ; Sun, 10 Nov 2013 01:55:41 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id b10so788505qcw.36 for ; Sat, 09 Nov 2013 17:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=z8x/rOHN/zT8BNb7WrPp3+bHUZzihHIqw8L9w/nN4oo=; b=eVYrJs/tMXNNNJ+ex/eX0CwCWwAKaXGG9wL/JcmBXJ6tO/eVH139RkDGEYPuJTa1Lg D3raMbyRui/ppl13cTqjuKfo6oU6NYX4Bvjzs0VqBRHwE/aqGZxP67nB+WvFpdFy1esh n/VNQOpHen8JPBe1TvFMqSMgIB4JE5n4nv6KlPoeliAuudK1w9AjsyyQRL0ddT+ei1X6 Apwhb+EQ+UTJr002eU/Zh+lLd1tWFAh/Er07ISLoru8zAf226ymqPRVzoQHaiBRb1noz Gc7o38s+GboTUI3IlqpBzpqPc3PQC+Cf9tgrUh/63vO53AwQimkUwtb4C7z4uP0RRcGx wIgw== MIME-Version: 1.0 X-Received: by 10.49.35.144 with SMTP id h16mr35086552qej.35.1384048540412; Sat, 09 Nov 2013 17:55:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 17:55:40 -0800 (PST) In-Reply-To: <527EE417.6060704@allanjude.com> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> <1383788977.14448.44112617.6F0D61A0@webmail.messagingengine.com> <527AFAA1.1040001@allanjude.com> <527BCA55.2000207@allanjude.com> <527C5D52.7030508@allanjude.com> <047405A8-B6EB-427B-A2E4-6254DD1A077B@orthanc.ca> <3E6377FF-69FE-48E4-BFB1-E5095A7FA1BB@orthanc.ca> <527C6DEF.6020102@allanjude.com> <527E3EB3.6000301@FreeBSD.org> <8034B822-F903-43D1-8BF6-DFAD7C22F5B0@gsoft.com.au> <527ED34A.1060401@allanjude.com> <527EE417.6060704@allanjude.com> Date: Sat, 9 Nov 2013 17:55:40 -0800 X-Google-Sender-Auth: R610XlNWYgnRmQ9-aFjDaZtZPGI Message-ID: Subject: Re: cron(8) improvement From: Adrian Chadd To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 10 Nov 2013 01:55:41 -0000 On 9 November 2013 17:40, Allan Jude wrote: > On 2013-11-09 20:05, Adrian Chadd wrote: >> On 9 November 2013 16:28, Allan Jude wrote: >> >>> Well, what about making these extra directories optional then? >>> >>> packages install the crontab entries, but crond ignores them unless you add: >>> >>> cron_flags="--scandir /etc/cron.d --scandir /usr/local/etc/cron.d" >>> >>> or something to that effect >>> >>> As for packages enabling things, this seems like a good use of the >>> /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, >>> where the individual files are only included if the name of the service >>> being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be >>> read when starting crond >> Right. I'd rather it read in everything, but I realise that scales poorly. >> >> The other alternative is to have a config file populated with the >> contents of /etc/rc.conf.d/*, so to modify it you'd edit the >> individual config file(s), then do a "commit" operation to push it >> into the cache. >> >> If the cache file doesn't exist, it simply goes through and reads * >> >> if someone wanted to speed up the rcvar set, they could just replace >> it with a read from an sqlite table or an individual config file (as >> said above); the rcvar thing is -supposed- to just be attribute=value, >> so it can be stored anywhere. >> >> Note to previous poster: i think the existing policy sucks. :-) >> >> >> -adrian > I suppose you could easily do something like: cat /etc/rc.conf.d/* > > /etc/rc.conf.cat > > and add rc.conf.cat to rc_conf_files Right. But what this scheme specifically needs is some semantics for "thing I do to push new config changes into the rc.conf system" and "thing I do to force a commit of these changes." For the rc.conf.cat version, it would do the above. It may just wrap it in a lock file. For the sqlite hack version, it would grab a lock and dump everything into an sqlite table. The point is that it shouldn't be adhoc. there should be some tools in base for "things" to add/remove cron configs, add/remove rc.conf configs, and do a "rebuild" of them. -adrian