Date: Sat, 8 Feb 2020 13:39:07 -0600 From: Kyle Evans <self@kyle-evans.net> To: Josh Aas <josh@kflag.net> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: updating cron and atrun Message-ID: <CACNAnaH52EcQUFR6dXzP7i-HGx=EuBEF7sHsYbiEb37_Q2ZfcA@mail.gmail.com> In-Reply-To: <CAJzSF_7N4A-_6LfjivWRirNkTHv3ANWu%2BBX6g1UOKqdYmDZZNA@mail.gmail.com> References: <CAJzSF_7N4A-_6LfjivWRirNkTHv3ANWu%2BBX6g1UOKqdYmDZZNA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 7, 2020 at 8:19 AM Josh Aas <josh@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=E2=80=99s 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=E2=80=99t 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=E2=80=99d still need to maintain or =E2=80=9Cupstream=E2=80=9D el= sewhere. > > I=E2=80=99d recommend continuing with the current status quo - keep FreeB= SD=E2=80=99s > 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=E2=80=99t very interest= ing > IMO. Seems very possible that the cost of that churn outweighs the > benefit. I=E2=80=99d love to hear more about why this is a particularly g= ood > idea if people believe it is. Maybe I=E2=80=99m missing something. > > If people agree I=E2=80=99d recommend removing the cron and atrun suggest= ion > 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 =E2=80=9Cideaslist=E2=80=9D? 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. =3D-) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaH52EcQUFR6dXzP7i-HGx=EuBEF7sHsYbiEb37_Q2ZfcA>