Re: cron(8) improvement

On Thu, Nov 7, 2013 at 6:43 AM, Lyndon Nerenberg <lyndon_at_orthanc.ca> wrote:
>
> On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala <kpaasial_at_gmail.com> wrote:
>
>> What's wrong with using the existing tools for achieving the same
>> effect? Periodic can be adapted to do exactly what you're describing
>> as noted above by adding an hourly (even minutely? :D ) periodic run.
>
> Periodic is geared towards periodic system maintenance tasks.  Once per day, once per week, once per month.  It doesn't deal with tasks that need to be fired off at arbitrary intervals.
>
> As you say, it could be adapted to run things with per-minute granularity, but it wouldn't scale well.  For per-minute granularity you would have to fire off a periodic run every minute.  That's five times the rate that atrun(8) kicks off at.  That's a lot of overhead for small, embedded, or power constrained systems.  And to get the time-granularity cron has, you would have to re-implement cron(8)s dispatch control as a set of shell functions.  That's just silly.
>
>
> --lyndon
>
>

Well ok, I get your point. I guess there's no other option than to add
support for a cron.d directory for crontab -snippets. I'd however like
to emphasize one thing that has been noted already:

- Snippets installed by ports should be disabled by default and
enabled only selectively by variables in rc.conf(5) or some other
configuration file to mirror what periodic(8) is doing now.  This is
an absolute must because having them enabled by default is a recipe
for disaster. Compare this to services installed by ports, none of
them are enabled by default.

-Kimmo