Re: cron(8) improvement

From: Adrian Chadd <adrian_at_freebsd.org>
Date: Sat, 9 Nov 2013 17:55:40 -0800
On 9 November 2013 17:40, Allan Jude <freebsd_at_allanjude.com> wrote:
> On 2013-11-09 20:05, Adrian Chadd wrote:
>> On 9 November 2013 16:28, Allan Jude <freebsd_at_allanjude.com> 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
Received on Sun Nov 10 2013 - 00:55:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC