From owner-freebsd-current@FreeBSD.ORG Thu Nov 7 01:56:34 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 850112F2 for ; Thu, 7 Nov 2013 01:56:34 +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 5B02D202B for ; Thu, 7 Nov 2013 01:56:34 +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 rA71uUR2048795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 6 Nov 2013 17:56:32 -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: <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> Date: Wed, 6 Nov 2013 17:56:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <42145521-3A5C-4936-B1AB-782E88F55CD8@orthanc.ca> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> To: FreeBSD Current X-Mailer: Apple Mail (2.1816) 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 01:56:34 -0000 > Support for a cron.d directory is a tool that can be > used in many ways. I have used cron.d on other UNIXen, and for package-installed cron jobs = I find it significantly friendlier, in that it makes these jobs easily = identifiable to the sysadmin. As we do it now, the per-user crontabs are quite opaque. It's easy to = get a list of the 'logins' that have them, but the best you can do is = cat the files and hope the entries are well documented or obvious from = context. And editing a single file from an installer script is always = subject to failure: it's hard to guard from failure if somebody comes = along and, in the course of manually editing the file, upsets the = markers the [un]installer scripts are looking for. Allowing a package to add/rm a self-contained file avoids these = accidental editing muckups. And with a simple standardized naming = convention, the mapping from cron files to packages can be both unique = and obvious. This is a big win for the sysadmin trying to track down a = mystery run-away cron job. Some attention must be given to setting things the uid/gid to run under, = and it might be useful to allow specification of things like the login = class, and perhaps capsicum capabilities. Actually, the latter two = features are useful in the general case. Regardless, the core idea is = both sound and useful. --lyndon