Revision tags: release/14.0.0 |
|
#
a9e160c3 |
| 02-Jun-2023 |
Elyes Haouas <ehaouas@noos.fr> |
cron/lib: Fix typos
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/653
|
#
aee3ee66 |
| 01-Jun-2023 |
Eric van Gyzen <vangyzen@FreeBSD.org> |
cron: fix build without LOGIN_CAP
Fixes: fe590ffe40f49fe09d8275fbf29f0d46c5b99dc7 MFC after: on demand Sponsored by: Dell EMC Isilon
|
#
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
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
show more ...
|
#
e93f27e3 |
| 18-Apr-2023 |
John Baldwin <jhb@FreeBSD.org> |
cron: Use C89 function definitions.
Reviewed by: zlei Differential Revision: https://reviews.freebsd.org/D39529
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
#
37cd6c20 |
| 04-Mar-2021 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
cron: consume blanks in system crontabs before options
On system crontabs, multiple blanks are not being consumed after reading the username. This change adds blank consumption before parsing any -[
cron: consume blanks in system crontabs before options
On system crontabs, multiple blanks are not being consumed after reading the username. This change adds blank consumption before parsing any -[qn] options. Without this change, an entry like:
* * * * * username -n true # Two spaces between username and option.
will fail, as the shell will try to execute (' -n true'), while an entry like:
* * * * * username -n true # One space between username and option.
works as expected (executes 'true').
For user crontabs, this is not an issue as the preceding (day of week or @shortcut) processing consumes any leading whitespace.
PR: 253699 Submitted by: Eric A. Borisch <eborisch@gmail.com> MFC after: 1 week
show more ...
|
Revision tags: release/12.2.0, release/11.4.0 |
|
#
89c7bb56 |
| 30-Mar-2020 |
Kyle Evans <kevans@FreeBSD.org> |
cron: respect PATH from login.conf
As a followup to the use of login.conf environment vars (other than PATH) in cron, this patch adds PATH (and HOME) to the list of login.conf settings respected.
T
cron: respect PATH from login.conf
As a followup to the use of login.conf environment vars (other than PATH) in cron, this patch adds PATH (and HOME) to the list of login.conf settings respected.
The new logic is as follows:
1. SHELL is always _PATH_BSHELL unless explicitly overridden in the crontab file itself; no other settings are respected. This is unchanged.
2. PATH is taken from the first of: crontab file, login.conf, _PATH_DEFPATH
3. HOME is taken from the first of: crontab file, login.conf, passwd entry, unset
4. The current directory for invoking the command is taken from the crontab file's value of HOME (existing behavior), or the passwd entry, but not anywhere else (so it might not equal HOME if that was set in login.conf).
Submitted by: Andrew Gierth <andrew_tao173.riddles.org.uk> Reviewed by: sigsys_gmail.com Differential Revision: https://reviews.freebsd.org/D23597
show more ...
|
Revision tags: release/12.1.0 |
|
#
668ee101 |
| 26-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r352587 through r352763.
|
#
5b80de23 |
| 25-Sep-2019 |
Kyle Evans <kevans@FreeBSD.org> |
cron: add log suppression and mail suppression for successful runs
This commit adds two new extensions to crontab, ported from OpenBSD: - -n: suppress mail on succesful run - -q: suppress logging of
cron: add log suppression and mail suppression for successful runs
This commit adds two new extensions to crontab, ported from OpenBSD: - -n: suppress mail on succesful run - -q: suppress logging of command execution
The -q option appears decades old, but -n is relatively new. The original proposal by Job Snijder can be found here [1], and gives very convincing reasons for inclusion in base.
This patch is a nearly identical port of OpenBSD cron for -q and -n features. It is written to follow existing conventions and style of the existing codebase.
Example usage:
# should only send email, but won't show up in log * * * * * -q date
# should not send email * * * * * -n date
# should not send email or log * * * * * -n -q date
# should send email because of ping failure * * * * * -n -q ping -c 1 5.5.5.5
[1]: https://marc.info/?l=openbsd-tech&m=152874866117948&w=2
PR: 237538 Submitted by: Naveen Nathan <freebsd_t.lastninja.net> Reviewed by: bcr (manpages) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D20046
show more ...
|
Revision tags: release/11.3.0, release/12.0.0, release/11.2.0 |
|
#
a08d12d3 |
| 08-Jun-2018 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Add new functionality and syntax to cron(1) to allow to run jobs at a given interval, which is counted in seconds since exit of the previous invocation of the job. Example user crontab entry:
@25 sl
Add new functionality and syntax to cron(1) to allow to run jobs at a given interval, which is counted in seconds since exit of the previous invocation of the job. Example user crontab entry:
@25 sleep 10
The example will launch 'sleep 10' every 35 seconds. This is a rather useless example above, but clearly explains the functionality.
The practical goal here is to avoid overlap of previous job invocation to a new one, or to avoid too short interval(s) for jobs that last long and doesn't have any point of immediate launch soon after previous run.
Another useful effect of interval jobs can be noticed when a cluster of machines periodically communicates with a single node. Running the task time based creates too much load on the node. Running interval based spreads invocations across machines in cluster. Note that -j/-J won't help in this case.
Sponsored by: Netflix
show more ...
|
Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0 |
|
#
cfe30d02 |
| 19-Jun-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge fresh head.
|
Revision tags: release/8.4.0, release/9.1.0 |
|
#
300675f6 |
| 27-Nov-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC
|
#
a10c6f55 |
| 11-Nov-2012 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r242684
|
#
23090366 |
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
#
7a5c30c5 |
| 26-Oct-2012 |
Maxim Sobolev <sobomax@FreeBSD.org> |
Second attempt to add @every_second keyword support. Due to multiple requests, default to the previous 60-seconds scheduling method unless there is any @every_second entries to conserve CPU cycles an
Second attempt to add @every_second keyword support. Due to multiple requests, default to the previous 60-seconds scheduling method unless there is any @every_second entries to conserve CPU cycles and power.
This change also improves scheduling in the default mode by running as close to the beginning of the minnute as possible by replacing sleep(3) with nanosleep(2). Previously, the tasks would run anywhere within the first second of the minute and that offset drifted back and forth each time cron(8) was engaged.
MFC after: 1 month
show more ...
|
#
27858d0b |
| 18-Oct-2012 |
Maxim Sobolev <sobomax@FreeBSD.org> |
Fully backout latest changes.
Pointy hat to: sobomax
|
#
07e9aac0 |
| 17-Oct-2012 |
Maxim Sobolev <sobomax@FreeBSD.org> |
Revert latest changes to cron, until better version is worked out (I hope).
Requested by: few
|
#
890278c1 |
| 16-Oct-2012 |
Maxim Sobolev <sobomax@FreeBSD.org> |
Properly handle non-keyword case by setting e->second to 0.
|
#
2543786a |
| 15-Oct-2012 |
Maxim Sobolev <sobomax@FreeBSD.org> |
Add per-second scheduling into the cron(8). Right now it's only available via the new @every_second shortcut. ENOTIME to implement crontab(5) format extensions to allow more flexible scheduling.
In
Add per-second scheduling into the cron(8). Right now it's only available via the new @every_second shortcut. ENOTIME to implement crontab(5) format extensions to allow more flexible scheduling.
In order to address some concerns expressed by Terry Lambert while discussing the topic few years ago, about per-second cron possibly causing some bad effects on /etc/crontab by stat()ing it every second instead of every minute now (i.e. atime update), only check that database needs to be reloaded on every 60-th loop run. This should be close enough to the current behaviour.
Add "@every_minute" shortcut while I am here.
MFC after: 1 month
show more ...
|
Revision tags: release/8.3.0_cvs, release/8.3.0 |
|
#
8fa0b743 |
| 23-Jan-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @230489 (pending review).
|
#
80dbff4e |
| 04-Jan-2012 |
Sean Bruno <sbruno@FreeBSD.org> |
IFC to head to catch up the bhyve branch
Approved by: grehan@
|
Revision tags: release/9.0.0 |
|
#
3df5ecac |
| 30-Dec-2011 |
Ulrich Spörlein <uqs@FreeBSD.org> |
Spelling fixes for usr.sbin/
|
Revision tags: release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0 |
|
#
e57c2b13 |
| 04-Dec-2008 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
integrate from head@185615
|
Revision tags: release/6.4.0_cvs, release/6.4.0 |
|
#
66d48cda |
| 10-Nov-2008 |
Matteo Riondato <matteo@FreeBSD.org> |
Make usr.sbin/cron/crontab and usr.sbin/cron/lib WARNS=3 clean
Tested with: make universe
MFC after: 3 days
|
Revision tags: release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0 |
|
#
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'
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
show more ...
|