#
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
|