History log of /freebsd-current/usr.sbin/cron/cron/database.c
Revision Date Author Comments
# fe590ffe 01-Jun-2023 Eric van Gyzen <vangyzen@FreeBSD.org>

Import vixie cron 4.0

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
Differential Revision: https://reviews.freebsd.org/D40260


# e93f27e3 18-Apr-2023 John Baldwin <jhb@FreeBSD.org>

cron: Use C89 function definitions.

Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D39529


# bd6174f7 19-Apr-2019 Kyle Evans <kevans@FreeBSD.org>

cron(8): schedule interval jobs that get loaded during execution

Jobs using the @<second> syntax currently only get executed if they exist
when cron is started. The simplest reproducer of this is:

echo '@20 root echo "Hello!"' >> /etc/cron.d/myjob

myjob will get loaded at the next second==0, but this echo job will not
run until cron restarts. These jobs are normally handled in
run_reboot_jobs(), which sets e->lastexit of INTERVAL jobs to the startup
time so they run 'n' seconds later.

Fix this by special-casing TargetTime > 0 in the database load. Preexisting
jobs will be handled at startup during run_reboot_jobs as normal, but if
we've reloaded a database during runtime we'll hit this case and set
e->lastexit to the current time when we process it. They will then run every
'n' seconds from that point, and a full restart of cron is no longer
required to make these jobs work.

Reported by: Juraj Lutter (otis_sk.freebsd.org)
Reviewed by: allanjude, bapt, bjk (earlier version), Juraj Lutter
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D19924


# a97c6445 12-Apr-2018 Kyle Evans <kevans@FreeBSD.org>

cron(8): Correct test sense

We're about to use the result of fstat(2) either way, so don't do that if it
fails...

X-MFC-With: r332429


# 1cb7491a 12-Apr-2018 Kyle Evans <kevans@FreeBSD.org>

cron(8): Reload database if an existing job in cron.d changed as well

Directory mtime will only change if a file is added or removed, not
modified. For /var/cron/tabs, this is fine because of how crontab(1) manages
it using temp files so all crontab(1) changes will trigger a reload of the
database.

For /etc/cron.d and /usr/local/etc/cron.d, this is not necessarily the case.
Instead of checking their mtime, we should descend into them and check mtime
on all jobs also.

Reported by: des
Reviewed by: bapt
MFC after: 1 week


# 569b9175 31-Oct-2016 Baptiste Daroussin <bapt@FreeBSD.org>

Allow symlinks to be followed in cron.d directories and fix detection of
regular files on NFS

Reported by: jilles


# b2fd8384 31-Oct-2016 Baptiste Daroussin <bapt@FreeBSD.org>

cron(8): add support for /etc/cron.d and /usr/local/etc/cron.d

For automation tools it is way easier to maintain files in directories rather
than modifying /etc/crontab.

The files in those directories are in the same format as /etc/crontab

Reviewed by: adrian
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D8400


# a7d5f7eb 19-Oct-2010 Jamie Gritton <jamie@FreeBSD.org>

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.


# fe0506d7 09-Mar-2010 Marcel Moolenaar <marcel@FreeBSD.org>

Create the altix project branch. The altix project will add support
for the SGI Altix 350 to FreeBSD/ia64. The hardware used for porting
is a two-module system, consisting of a base compute module and a
CPU expansion module. SGI's NUMAFlex architecture can be an excellent
platform to test CPU affinity and NUMA-aware features in FreeBSD.


# d7f03759 19-Oct-2008 Ulf Lilleengen <lulf@FreeBSD.org>

- Import the HEAD csup code which is the basis for the cvsmode work.


# 784bddbc 07-Nov-2007 Kevin Lo <kevlo@FreeBSD.org>

Cleanup of userland __P use


# 997c6eef 17-Jun-2007 Yaroslav Tykhiy <ytykhiy@gmail.com>

Add PAM support to cron(8). Now cron(8) will skip commands scheduled
by unavailable accounts, e.g., those locked, expired, not allowed in at
the moment by nologin(5), or whatever, depending on cron's pam.conf(5).
This applies to personal crontabs only, /etc/crontab is unaffected.

In other words, now the account management policy will apply to
commands scheduled by users via crontab(1) so that a user can no
longer use cron(8) to set up a delayed backdoor and run commands
during periods when the admin doesn't want him to.

The PAM check is done just before running a command, not when loading
a crontab, because accounts can get locked, expired, and re-enabled
any time with no changes to their crontabs. E.g., imagine that you
provide a system with payed access, or better a cluster of such
systems with centralized account management via PAM. When a user
pays for some days of access, you set his expire field respectively.
If the account expires before its owner pays more, its crontab
commands won't run until the next payment is made. Then it'll be
enough to set the expire field in future for the commands to run
again. And so on.

Document this change in the cron(8) manpage, which includes adding
a FILES section and touching the document date.

X-Security: should benefit as users have access to cron(8) by default


# 97d92980 27-Aug-1999 Peter Wemm <peter@FreeBSD.org>

$Id$ -> $FreeBSD$


# 401e6468 15-Sep-1997 Philippe Charnier <charnier@FreeBSD.org>

Use err(3). Rewrote man page in mdoc format.


# 476602a9 22-Feb-1997 Peter Wemm <peter@FreeBSD.org>

Revert $FreeBSD$ to $Id$


# 1130b656 14-Jan-1997 Jordan K. Hubbard <jkh@FreeBSD.org>

Make the long-awaited change from $Id$ to $FreeBSD$

This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.


# bdddbd2f 16-Dec-1996 Paul Traina <pst@FreeBSD.org>

Replace my "inane" usage of snprintf to copy strings with strncpy as
used by OpenBSD. (Quite frankly, I think it's perfectly reasonable to
use snprintf to copy strings, given that the semantics for strncpy()
are utterly idiotic and there is no POSIX sstrncpy().)

While I'm at it, incorporate some of OpenBSD's bugfixes to cron.

NOT for 2.2


# 73b26063 09-Sep-1996 Peter Wemm <peter@FreeBSD.org>

personal (ie: with the crontab command) cron tabs were broken by the
last change. :-(
ie: /var/cron/log would report: .. cron[206]: (usage) CAN'T OPEN (%s/%s)


# 30aaae26 08-Sep-1996 Paul Traina <pst@FreeBSD.org>

Fix some buffer overflow problems...


# 84f33dea 27-Aug-1994 Jordan K. Hubbard <jkh@FreeBSD.org>

Paul Vixie's cron, version 3.0. Munged into bmake format. If this goes
well, expect our two seperate directories for cron and crontab to go away
shortly.
Submitted by: jkh