Re: cron(8) improvement

On 2013-11-09 20:55, Adrian Chadd wrote:
> 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
Well, if the rc.conf config is specific to the daemon being installed by
the package, then the existing /etc/rc.conf.d/ system works fine, it
just falls down a little on xorg configuring hald, unless you just make
the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus


I like the simplicity of rc.conf, and I would much rather not involve an
sqlite database, I am not sure how that could possibly be faster then
sourcing an extra shell script.

-- 
Allan Jude