Import vixie cron 4.0

[vangyzen]

Summary

Specifically, import the diff from commit e745bd4c10ab to
commit 83563783cc2 in https://github.com/vixie/cron.git

My sole motivation is changing to the common MIT license.
The old license, especially the "buildable source" clause,
is unfriendly for commercial users of this code. Simply
changing the license without importing [most of] the code
accompanying that license seemed legally dubious.

The most regrettable change is losing Paul's uucp path.
I partially atone for this loss by restoring the upstream
$Id$ tags, since $FreeBSD$ is no longer useful.

This is [intended to be] a complete list of the functional
changes in this commit. Some changes were made so that we
could consider vixie cron to be our upstream and reduce our
diffs against it, while others were simply a good idea.

• main() - use putenv instead of setenv for PATH
• open_pidfile no longer needs snprintf to build pidfile
• crontab main() - abort() on impossible errors
• check for truncation when building strings with snprintf
• getdtablesize() -> sysconf(_SC_OPEN_MAX)

These changes were not taken from upstream's 4.0 diff because
they [could] actually change behavior. Some of them might be
beneficial, but should be taken separately.

• config.h - sendmail args: remove -oi and add -or0s
• call setlocale(LC_ALL, "") at the top of main()
• acquire_daemonlock - we already use pidfile
• cast getpid(), uid_t, and gid_t to long for printf
• remove unnecessary braces - I consider them beneficial
• BSDi support
• glue_strings() - use snprintf(), as we often already did

MFC after: on demand
Sponsored by: Dell EMC Isilon

Test Plan

• The periodic daily and security jobs ran correctly.
• Simple jobs ran correctly from my user's crontab.
• crontab -e/-r/-l worked as normal.
• Mail from such jobs was delivered as normal.

[cy]

I think the best approach would be to import through the vendor branch and put it in contrib/cron, and altering the makefiles to contrib/cron instead. The vendor branch provides a better degree of maintainability.

[vangyzen]

I think the best approach would be to import through the vendor branch and put it in contrib/cron, and altering the makefiles to contrib/cron instead. The vendor branch provides a better degree of maintainability.

Although that is certainly true of most third-party code, it's not so clear for cron. It does not already exist on the vendor branch. The last import from vixie is the commit that initially added cron to the FreeBSD tree in 1994. Since then, 234 commits have essentially forked cron into FreeBSD's own version. We have taken changes from multiple other sources, including NetBSD and OpenBSD. The repo from which I took the present change is not clearly active enough to be considered our "new" vendor for cron: except for a handful of recent commits, it has been essentially idle for almost 20 years. Even if it were, our divergence might make the vendor-update procedure more trouble than it's worth.

[delphij]

The OpenBSD fork is worth looking (I had a version of FreeBSD with the OpenBSD fork of cron in the svn age, but never got a chance to conclude the work and merge it) too. They have also merged atrun into cron to give it better time precision and reduce spams for logs.

(The change looked good to me in a quick glance so consider this as a LGTM, as it would reduce diff against both of the upstream and OpenBSD fork).

[imp]

I'd think that doing a vendor branch with OpenBSD as the upstream might be ideal.
This code seems mostly fine, though, and I'm generally on board with the idea.

[vangyzen]

Thank you both for the feedback. I like the idea of using OpenBSD as an upstream, but that would take a lot more time than I have right now. (Most or all of my FreeBSD time is on Dell's clock.)

[emaste]

I have no objection to this approach (but have not reviewed the diff in detail yet).

[vangyzen]

In D40260#919297, @emaste wrote:

I have no objection to this approach (but have not reviewed the diff in detail yet).

I just saw this, right after committing to main. Of course, I'll be happy to fix any issues. Thank you for the review, both the approach and the code.