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
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
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
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
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
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
as crontab(5) states it can be. This is supported by all vixie-cron derived
implementations; not sure why FreeBSD was any different.
PR: bin/106442
MFC after: 2 weeks
entry having stepping value of zero can cause crontab to hang there,
and if the main crontab is being changed in this way, then cron(8)
will keep spining.
Obtained from: OpenBSD [src/usr.sbin/cron/entry.c,v 1.17]
PR: 68683 (my own, but forgot to commit it...)
MFC After: 1 week
monthly and weekly, respectively. Also fix the @yearly shortcut so
that it doesn't execute daily during January. OpenBSD and NetBSD also
appear to have this bug.
PR: bin/21152
e->cmd. free_entry() now does the right thing with
partially-initialized structures.
load_entry(): Don't call env_free() on e->envp throughout the routine
before jumping to eof; the free_entry() call at that label will take
care of it. The previous behavior resulted in e->envp being free'd
twice (well, the second time would usually result in a crash, but
that's besides the point); once in load_entry(), and once in
free_entry() after the former called the latter. Also note that the
check added to free_entry() (above) doesn't help, since e->envp wasn't
reset to NULL after env_free().
Submitted by: Mark Peek <mark@whistle.com>
Fix setting of "hour" bitmap when @hourly keyword is specified.
MFC candidate after 4.0-RELEASE.
Problem-found-by: Sheldon Hearn <sheldonh@uunet.co.za>
Use getpwnam before getpwuid since two users with same uids can exists
(affects new login classes code only)
The same fixes as in inetd: by default run `system crontab things' with
daemon login class now, not restrict them to user class breaking
compatibility with old way (so-called nobody limits problem)
Implement user[:group][/login-class] syntax in system crontab
for more flexible control (the same as in inetd)
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.
