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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

All,

someone brought this up on the chat channel today, so I'm bringing it
here to ask for information.

Is there a reason we still use run-parts and the
/etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?

From what I read in the chat earlier, it sounds like the modern crons
might be able to handle this without that structure, but I'm not sure.

Thanks,

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Orlitzky]

On 3/2/19 7:05 PM, William Hubbs wrote:
> 
> Is there a reason we still use run-parts and the
> /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
> 
> From what I read in the chat earlier, it sounds like the modern crons
> might be able to handle this without that structure, but I'm not sure.

https://bugs.gentoo.org/69777

Totally. We should replace run-parts with something much simpler and
more predictable. Then, if that doesn't work for you, all modern crons
can do the things that run-parts tries to do, but better.

Basically: if I choose vixie-cron, then let me get the vixie-cron
behavior. Or if I choose something more modern, get out of the way.

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

[Rich Freeman]

On Sat, Mar 2, 2019 at 7:05 PM William Hubbs <williamh@gentoo.org> wrote:
>
> someone brought this up on the chat channel today, so I'm bringing it
> here to ask for information.
>
> Is there a reason we still use run-parts and the
> /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
>
> From what I read in the chat earlier, it sounds like the modern crons
> might be able to handle this without that structure, but I'm not sure.
>

Are you proposing getting rid of run-parts?   Or are you proposing
getting rid of /etc/cron.*?

run-parts is part of debianutils, and ca-certificates apparently uses
it, so trying to purge that might not go far.  I don't think it is
directly in @system so it would go away on its own if it wasn't used.
Some of the cron implementations also use it, and some don't, and each
one can pull it in as needed I suppose.

I don't think you can get rid of the cron.* directories, since that is
the least-common-denominator way for packages to install scripts for
cron to run.  If we wanted to do something else we'd probably need
some kind of eclass that knows how to install a cron script for any of
the various cron implementations out there.  We can't really even just
go to generic cron syntax for some kind of crontab.d handler because I
don't think that is standardized for tasks that are to run if their
scheduled time is missed.

I suspect that maintainers of cron implementations that don't require
run-parts probably already avoid using it.

Maybe you had something specific in mind that I missed?

-- 
Rich

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

[Rich Freeman]

On Sat, Mar 2, 2019 at 7:26 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 3/2/19 7:05 PM, William Hubbs wrote:
> >
> > Is there a reason we still use run-parts and the
> > /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
> >
> > From what I read in the chat earlier, it sounds like the modern crons
> > might be able to handle this without that structure, but I'm not sure.
>
> https://bugs.gentoo.org/69777
>
> Totally. We should replace run-parts with something much simpler and
> more predictable. Then, if that doesn't work for you, all modern crons
> can do the things that run-parts tries to do, but better.
>

I'm not sure I see the connection here.  All run-parts does is run all
the scripts in a directory.  That seems pretty simple and
deterministic.

The bug is about cronbase, which contains run-crons, along with
installing the cron.d directories.  I could see an argument for
splitting that package though obviously the package is already pretty
simple.

I imagine most cron implementations do not use run-crons.  Whether any
particular one (like vixie-cron) should seems like a matter of taste.

Are we just talking about not having vixie-cron use run-crons?  And
instead having it just have time-scheduled jobs for run-parts on the
various cron.* directories?  That seems a bit narrower in scope than
what was originally suggested, though it isn't clear to me what is
being suggested...

-- 
Rich

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

[Michael Orlitzky]

On 3/2/19 7:44 PM, Rich Freeman wrote:
>>
>> Totally. We should replace run-parts with something much simpler and
>> more predictable. Then, if that doesn't work for you, all modern crons
>> can do the things that run-parts tries to do, but better.
>>
> 
> I'm not sure I see the connection here.  All run-parts does is run all
> the scripts in a directory.  That seems pretty simple and
> deterministic.
> 

Oof, yeah, sorry. I thought we were talking about *run-crons* and not
*run-parts*. We should get rid of *run-crons*, which is installed by
cronbase and used by vixie-cron, fcron, bcron, and dcron (according to
grep).

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.

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

[Rich Freeman]

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

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

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 306 bytes --]

On 3/3/19 1:05 AM, William Hubbs wrote:
> /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
I'm not 100% but IMO for a desktop this seems works whereas @daily or @weekly in crontab works only for systems running 24h per day, isn't it?

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ralph Seichter]

* Toralf Förster:

> I'm not 100% but IMO for a desktop this seems works whereas @daily or
> @weekly in crontab works only for systems running 24h per day, isn't
> it?

That depends on what flavour of cron is used (see https://en.wikipedia.org/wiki/Anacron).

-Ralph

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

[Michael Orlitzky]

On 3/2/19 9:01 PM, Rich Freeman wrote:
> 
> 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.

vixie-cron's crontab has a "user" field

The rest of this post sounds like it's conflating the two issues
again... which is completely my fault. I saw "run-" and got triggered. I
think I've said everything that can be said against run-crons on the
bug. I don't have any better ideas for the run-parts scheme.