updating cron and atrun

[Kyle Evans]

On Fri, Feb 7, 2020 at 8:19 AM Josh Aas <josh at kflag.net> wrote:
>
> I was looking for a way to contribute to FreeBSD and I decided to look
> into the cron/atrun project listed on this page:
>
> https://wiki.freebsd.org/IdeasPage#Improve_cron.288.29_and_atrun.288.29
>
> I looked into the current code, commits from the past decade, and the
> lineage of other versions of cron to see if there is a reasonable plan
> for updating FreeBSD’s cron based on another version. It doesn't seem
> like there are any particularly productive new path to take here. ISC
> cron is old and unmaintained, and I don’t think NetBSD or OpenBSD cron
> is interesting enough to be worth entirely rebasing on. On top of
> that, FreeBSD cron seems to have some FreeBSD-specific functionality
> that we’d still need to maintain or “upstream” elsewhere.
>
> I’d recommend continuing with the current status quo - keep FreeBSD’s
> version of cron and occasionally pull in security/stability patches as
> applicable from OpenBSD or NetBSD. The other options are a lot of work
> for little (if any) gain. Happy to hear other opinions though.
>
> Integrating atrun into cron might be nice but isn’t very interesting
> IMO. Seems very possible that the cost of that churn outweighs the
> benefit. I’d love to hear more about why this is a particularly good
> idea if people believe it is. Maybe I’m missing something.
>
> If people agree I’d recommend removing the cron and atrun suggestion
> on the Ideas Page. Maintaining that page seems like a pain though,
> might I recommend keeping track of these ideas as bugzilla bugs,
> tagged with something like “ideaslist”? Then you can just link to that
> search.
>

Hi,

I'd be inclined to agree- with cron, we've pulled in some features
from OpenBSD and I suspect it'd be easier to continue to do so as our
path forward. For anyone's general curiosity, below is an email I
wrote when asked about bringing in OpenBSD's (or any new)
implementation whole-sale; it's not a complete assessment of our local
changes/status, but my thoughts on bare minimum extra work needed to
bring in any other implementation.

---

Hello!

I'm actually mostly indifferent to cron(8) -- I've just been taking up
patches otherwise not getting any attention. =-)

These are the main things we'd probably want to audit/ensure are
available in any new implementation:
- MAILFROM support
- /etc/cron.d and /usr/local/etc/cron.d support
- making sure any new implementation properly registers changes to
files within as requiring a database reload

Worth noting is that we also support @every_minute and @every_second,
and @<second> syntax that would need to be reimplemented -- I don't
know about the first two, but I know that we have active users of
@<second> as I've fielded bug reports from one group of them that uses
it for $work-type stuff.

Some of our recent additions are ports from OpenBSD, like -n and -q
per-job flags.

Thanks,

Kyle Evans