Date: Wed, 6 Nov 2013 17:56:02 -0800 From: Lyndon Nerenberg <lyndon@orthanc.ca> To: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: cron(8) improvement Message-ID: <42145521-3A5C-4936-B1AB-782E88F55CD8@orthanc.ca> In-Reply-To: <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com> References: <52792B60.1030309@allanjude.com> <488180AE-5C23-402A-BAA4-E3263D8C52BF@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42145521-3A5C-4936-B1AB-782E88F55CD8>