src/etc/crontab, branch release/6.3.0

Clarify adjkerntz(8) note and use complete sentences in comments.

2002-11-22T16:13:39Z

PR: misc/45493 Approved by: re (rwatson)

Move the sendmail -q from cron to periodic, as suggested by a few people.

2001-02-19T02:47:42Z

This has the benefit of adding a random start time element as daily processing takes a different amount of time on different machines.

Manually run /usr/sbin/sendmail -q once a day. Folks seem to be too

2001-02-15T01:34:37Z

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.

Move the process of storing entropy from /dev/random and reseeding with

2001-01-14T07:18:31Z

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.

Add a system to save entropy from /dev/random periodically so that

2001-01-11T13:01:20Z

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.

Revert back to rev 1.24 as we have not come to a consensus if is is OK

2000-12-11T18:38:49Z

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.

Run all three maintenance script in succession, making sure they always

2000-12-11T17:31:44Z

run on the right day but never overlap. Submitted by: Giorgos Keramidas

On Sundays through Fridays, run daily at 03:01 am.

2000-12-10T12:54:34Z

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.

Run weekly a little bit later to give more time for daily to complete

2000-12-08T10:55:33Z

(since it starts later now).

When to run the periodic/daily event has had several rounds of discussion

2000-11-19T18:16:46Z

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.