Re: [gentoo-dev] rfc: cron.* and modern cron implementations

[Rich Freeman <rich0@gentoo.org>]

On Sat, Mar 2, 2019 at 8:25 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> Using run-parts in /etc/crontab also has its problems, but I don't have
> a solution handy for that one. Using run-parts runs those daily, weekly,
> etc. jobs as root, which may not be what you want if you're operating on
> user-controlled data (e.g. bug 662438). The best way to solve this would
> be to let packages install their own crontab entries into a directory
> like /etc/cron.d, but that location isn't standard.
>

So, the problem with cron.d is that you're now using crontab syntax,
and for compatibility you have to use the lowest common denominator
which is vixie.

That means your jobs are STILL running as root, so the only problem
you had with run-parts isn't solved.

In addition you lose the ability to cover the desktop use case of
non-24x7 systems running infrequent tasks.  If you used vixie cron
syntax for a monthly job it might never run at all on a typical
desktop, as it would have one opportunity to run in a month, at one
time of day.

The crontab syntax also forces each package maintainer to pick the
time of day their jobs run at, vs just letting the sysadmin choose the
time the entire set of scripts is run.

I'm sure there are alternatives like adding a compatibility layer
(which is basically what run-crons already is), or some kind of helper
where an ebuild can give it a set of parameters and it installs the
task for whatever cron implementation eselect points it at.  I'm just
not sure that they are worth the complexity or provide much more value
than the existing solutions.  This is also somewhat orthogonal to
run-crons, where you still are left with the choice around whether to
use it with vixie or other implementations that don't support more
desktop-oriented use cases.

This is of course why that bug has been fairly intractable.

-- 
Rich