The default crontab prior to this commit assumes atrun(8) is always
present, which isn't true if MK_AT == no. Move atrun(8) execution
from /etc/crontab to /etc/cron.d/at, and base /etc/cron.d/at's installation
on MK_AT. cron(8) will detect /etc/cron.d/at's presence when the configuration
is loaded and run atrun every 5 minutes like it would prior to this commit.
SHELL and PATH are duplicated between /etc/crontab and /etc/cron.d/at
because atrun(8) executes programs, which may rely on environment
set in the current default /etc/crontab.
Noted by: bdrewery (in an internal review)
MFC after: 2 months
Relnotes: yes (may need to add environmental modifications to
/etc/cron.d/at)
Sponsored by: Dell EMC Isilon
Install /etc/cron.d/at if MK_AT != no, always using it, which tries
to run a non-existent program via cron(8) every 5 minutes with the
default /etc/crontab, prior to this commit.
SHELL and PATH are duplicated between /etc/crontab and /etc/cron.d/at
because atrun(8) executes programs, which may rely on environment
currently set via /etc/crontab.
Noted by: bdrewery (in an internal review)
MFC after: 2 months
Relnotes: yes (may need to add environmental modifications to
/etc/cron.d/at)
Sponsored by: Dell EMC Isilon
trigger happy and turn off sendmail_enable entirely (instead of setting
sendmail_flags to -q30m instead). I have seen boxes with things like daily
run reports that have sat in mailq for 5 months. Since /usr/sbin/sendmail
is actually mailwrapper, this should be safe for the other plugins that
provide the sendmail calling interface.
it at boot time closer to the way we want it to be in the final version.
* Move the default directory to /var/db/entropy
* Run the entropy saving cron job every 11 minutes. This seems
to be a better default, although still bikeshed material.
* Feed /dev/random some cheesy "entropy" from various commands
and files before the disks are mounted. This gives /dev/random
a better chance of running without blocking early.
* Move the reseeding with previously stored entropy to the point
immediately after the disks are mounted.
* Make the harvesting script a little safer in regards to the
possibility of accidentally overwriting something other
than a regular file.
it can be used to reseed at boot time. This will greatly increase
the chances that there will be sufficient entropy available at
boot time to prevent long delays.
For /etc/rc, remove the vmstat and iostat runs from the attempt
to provide some cheesy randomness if the files fail, since
those programs are dynamically linked, and ldd seems to want
some randomness to do its magic.
Guidance and parameters for this project were provided by
Mark Murray, based on the requirements of the Yarrow
algorithm. Some helpful suggestions for implementation
(including the tip about iostat and vmstat) were provided
by Sheldon Hearn. All blame for problems or mistakes is
mine of course.
for a hung `daily' run to keep a `weekly' run from happening.
Same for `monthly'. We have always run `weekly' and `monthly' reguardless
of the execution status of `daily'. Until there is some consensus we should
not change the behavior.
On Saturdays, run daily and weekly sequentially, starting at 03:01 am.
This prevents daily and weekly from overlapping, while running weekly as
early as possible (i.e. as soon as daily finishes) to give it time to
finish before monthly starts at 05:30 am.
It's probably possible to do something similar with monthly, making it
run as soon as daily (and possibly weekly, if the first of the month
is a Saturday) finishes, but this is left as an exercise for the reader.
over the past couple years. The most recent came to the general consensus
that this was the best time, but no one actually made the change, so I'll
don my asbestos undies and dive in.
Please note that this time was chosen with input from people in various
countries with various methods and schedules for switching to and from DST.
There is no perfect time to schedule this job that works for everyone, but
this time both A) Works for more people, and B) Causes problems for fewer
people. And, ultimately, you can always change it if you need to.
All periodic sub-scripts <larf> now have their return codes interpreted
by periodic(8). Output may be masked based on variable values in
periodic.conf.
It's also now possible to email periodic output to arbitrary addresses,
or to send it to a log file, examples of which can be found in
newsyslog.conf.
The upshot of it all should be no discernable changes to the default
behaviour of periodic(8).
PR: 21250
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.
"hand", changed /etc/crontab to call /usr/sbin/newsyslog every hour
(the entry was there before - but we haven't had any newsyslog until
today :-) and changed /etc/inetd.conf to also contain (commentet out)
entries for rpc.rquotad and rpc.sprayd (taken from NetBSD)
only once an hour instead of every five minutes. This was due to a minute
specification of 0/5 -- which should have been */5. This has been fixed.
Expect your /var/cron/log to grow much faster now.
Further it implements crontab -e.
I moved cron from /usr/libexec to /usr/sbin where most daemons are
that are run from rc. That also gets rid of the ugly path crond
used to have in ps(1) outputs. Further I renamed it to cron, as
Paul Vixie likes it and is done by NetBSD.
NOTE VERY WELL THE FOLLOWING:
1) Systems crontab changed. Every users crontab resides in /var/cron
*EXCEPT* root's. This is a special crontab as it resides in
/etc. Further it is the *ONLY* crontab file in which you specify
usernames. See /usr/src/etc/crontab. This is also done by BSDI's
BSD/386 as far as I know (they provided the patches for it anyway)
2) So you *must* delete root's crontab and reinstall the copy
in /etc from /usr/src/etc.
'Must' is to much: the old installed crontab will work but cron
will also try to 'run' /etc/crontab.
3) Last but not least: cron's logging is now done via syslog. Note
that logging by cron is done lowercase when it logs about itsself
and uppercase when it logs user events, like installing a new crontab.
The default logfile file is the same as before:
syslog.conf:cron.* /var/cron/log
-Guido
