diff options
Diffstat (limited to 'usr.sbin/cron/doc')
| -rw-r--r-- | usr.sbin/cron/doc/CHANGES | 157 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/CONVERSION | 84 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/FEATURES | 83 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/INSTALL | 91 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/MAIL | 473 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/Makefile.vixie | 124 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/README | 68 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/README.1ST | 4 | ||||
| -rw-r--r-- | usr.sbin/cron/doc/THANKS | 29 |
9 files changed, 1113 insertions, 0 deletions
diff --git a/usr.sbin/cron/doc/CHANGES b/usr.sbin/cron/doc/CHANGES new file mode 100644 index 000000000000..84146a59b2be --- /dev/null +++ b/usr.sbin/cron/doc/CHANGES @@ -0,0 +1,157 @@ +-------- + +Vixie Cron Changes from V2 to V3 +Paul Vixie +29-Dec-1993 + +The crontab command now conforms to POSIX 1003.2. This means that when you +install it, if you have any "crontab" command lines floating around in shell +scripts (such as /etc/rc or /etc/rc.local), you will need to change them. + +I have integrated several changes made by BSDi for their BSD/386 operating +system; these were offerred to me before I started consulting for them, so +it is safe to say that they were intended for publication. Most notably, +the name of the cron daemon has changed from "crond" to "cron". This was +done for compatibility with 4.3BSD. Another change made for the same reason +is the ability to read in an /etc/crontab file which has an extra field in +each entry, between the time fields and the command. This field is a user +name, and it permits the /etc/crontab command to contain commands which are +to be run by any user on the system. /etc/crontab is not "installed" via +the crontab(1) command; it is automatically read at startup time and it will +be reread whenever it changes. + +I also added a "-e" option to crontab(1). Nine people also sent me diffs +to add this option, but I had already implemented it on my own. I actually +released an interim version (V2.2, I think) for limited testing, and got a +chance to fix a bad security bug in the "-e" option thanks to XXX. + +The daemon used to be extraordinarily sloppy in its use of file descriptors. +A heck of a lot of them were left open in spawned jobs, which caused problems +for the daemon and also caused problems with the spawned jobs if they were +shell scripts since "sh" and "csh" have traditionally used hidden file +descriptors to pass information to subshells, and cron was causing them to +think they were subshells. If you had trouble with "sh" or "csh" scripts in +V2, chances are good that V3 will fix your problems. + +About a dozen people have reminded me that I forgot to initialize +"crontab_fd" in database.c. Keith Cantrell was the first, so he gets the +point. + +Steve Simmons reminded me that once an account has been deleted from the +system, "crontab -u USER -d" will not work. My solution is to suggest to +all of you that before you delete a user's account, you first delete that +user's crontab file if any. From cron's point of view, usernames can never +be treated as arbitrary strings. Either they are valid user names, or they +are not. I will not make an exception for the "-d" case, for security +reasons that I consider reasonable. It is trivial for a root user to delete +the entry by hand if necessary. + +Dan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of +others also reminded me of this, but Dan gets the point. I didn't fix it +there, since the real bug was that it should have been open in the parent. + +Peter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in +misc.c. Hans Trompert actually told me first, but Peter sent the patch so +he gets the point. + +Russell Nelson told me that I'd forgotten to "#include <syslog.h>" in misc.c, +which explains why a lot of other people complained that it wasn't using +syslog even when they configured it that way :-). Steve Simmons told me +first, though, so he gets the point. + +An interim version of the daemon tried to "stat" every file before +executing it; this turned out to be a horribly bad idea since finding the +name of a file from a shell command is a hard job (that's why we have +shells, right?) I removed this bogus code. Dave Burgess gets the point. + +Dennis R. Conley sent a suggestion for MMDF systems, which I've added to the +comments in cron.h. + +Mike Heisler noted that I use comments in the CONVERSION file which are +documented as illegal in the man pages. Thanks, Mike. + +Irving Wolfe sent me some very cheerful changes for a NeXT system, but I +consider the system itself broken and I can't bring myself to #ifdef for +something as screwed up as this system seems to be. However, various others +did send me smaller patches which appear to have cause cron to build and run +correctly on (the latest) NeXT machines, with or without the "-posix" CFLAG. +Irving also asked for a per-job MAILTO, and this was finally added later when +I integrated the BSD/386 changes contributed by BSDi, and generalized some of +the parsing. + +Lots of folks complained that the autogenerated "Date:" header wasn't in +ARPA format. I didn't understand this -- either folks will use Sendmail and +not generate a Date: at all (since Sendmail will do it), or folks will use +something other than Sendmail which won't care about Date: formats. But +I've "fixed" it anyway... + +Several people suggested that "*" should be able to take a "/step". One person +suggested that "N/step" ought to mean "N-last/step", but that's stretching things +a bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb +sent in the first and most polite request for this feature. + +As with every release of Cron, BIND, and seemingly everything else I do, one +user stands out with the most critical but also the most useful analysis. +Cron V3's high score belongs to Peter Holzer, who sent in the nicest looking +patch for the "%" interpretation problem and also helped me understand a +tricky bit of badness in the "log_fd" problem. + +agulbra@flode.nvg.unit.no wins the honors for being the first to point out the +nasty security hole in "crontab -r". 'Nuff said. + +Several folks pointed out that log_it() needed to exist even if logging was +disabled. Some day I will create a tool that will compile a subsystem with +every possible combination and permutation of #ifdef options, but meanwhile +thanks to everybody. + +job_runqueue() was using storage after freeing it, since Jordan told me back +in 1983 that C let you do that, and I believed him in 1986 when I wrote all +this junk. Linux was the first to die from this error, and the Linux people +sent me the most amazing, um, collection of patches for this problem. Thanks +for all the fish. + +Jeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's +version of popen/pclose from the ftpd and hacked it to taste. We're safe now, +from this at least. + +Branko Lankester sent me a very timely and helpful fix for a looming security +problem in my "crontab -e" implementation. + +-------- + +Vixie Cron Changes from V1 to V2 +Paul Vixie +8-Feb-1988 + +Many changes were made in a rash of activity about six months ago, the exact +list of which is no longer clear in my memory. I know that V1 used a file +called POKECRON in /usr/spool/cron to tell it that it was time to re-read +all the crontab files; V2 uses the modtime the crontab directory as a flag to +check out the crontab files; those whose modtime has changed will be re-read, +and the others left alone. Note that the crontab(1) command will do a utimes +call to make sure the mtime of the dir changes, since the filename/inode will +often remain the same after a replacement and the mtime wouldn't change in +that case. + +8-Feb-88: made it possible to use much larger environment variable strings. + V1 allowed 100 characters; V2 allows 1000. This was needed for PATH + variables on some systems. Thanks to Toerless Eckert for this idea. + E-mail: UUCP: ...pyramid!fauern!faui10!eckert + +16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to + /usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny}, + since the sysv naming for this depends on 'at' using the same + dir, which would be stupid (hint: use /usr/{lib,spool}/at). + +22-Feb-88: made it read the spool directory for crontabs and look each one + up using getpwnam() rather than reading all passwds with getpwent() + and trying to open each crontab. + +9-Dec-88: made it sync to :00 after the minute, makes cron predictable. + added logging to /var/cron/log. + +14-Apr-90: (actually, changes since December 1989) + fixed a number of bugs reported from the net and from John Gilmore. + added syslog per Keith Bostic. security features including not + being willing to run a command owned or writable by other than + the owner of the crontab 9not working well yet) diff --git a/usr.sbin/cron/doc/CONVERSION b/usr.sbin/cron/doc/CONVERSION new file mode 100644 index 000000000000..6067650fa683 --- /dev/null +++ b/usr.sbin/cron/doc/CONVERSION @@ -0,0 +1,84 @@ + +Conversion of BSD 4.[23] crontab files: + +Edit your current crontab (/usr/lib/crontab) into little pieces, with each +users' commands in a different file. This is different on 4.2 and 4.3, +but I'll get to that below. The biggest feature of this cron is that you +can move 'news' and 'uucp' cron commands into files owned and maintainable +by those two users. You also get to rip all the fancy 'su' footwork out +of the cron commands. On 4.3, there's no need for the 'su' stuff since the +user name appears on each command -- but I'd still rather have separate +crontabs with separate environments and so on. + +Leave the original /usr/lib/crontab! This cron doesn't use it, so you may +as well keep it around for a while in case something goes wakko with this +fancy version. + +Most commands in most crontabs are run by root, have to run by root, and +should continue to be run by root. They still have to be in their own file; +I recommend /etc/crontab.src or /usr/adm/crontab.src. + +'uucp's commands need their own file; how about /usr/lib/uucp/crontab.src? +'news' also, perhaps in /usr/lib/news/crontab.src... + +I say `how about' and `perhaps' because it really doesn't matter to anyone +(except you) where you put the crontab source files. The `crontab' command +COPIES them into a protected directory (CRONDIR/SPOOL_DIR in cron.h), named +after the user whose crontab it is. If you want to examine, replace, or +delete a crontab, the `crontab' command does all of those things. The +various `crontab.src' (my suggested name for them) files are just source +files---they have to be copied to SPOOLDIR using `crontab' before they'll be +executed. + +On 4.2, your crontab might have a few lines like this: + + 5 * * * * su uucp < /usr/lib/uucp/uudemon.hr + 10 4 * * * su uucp < /usr/lib/uucp/uudemon.day + 15 5 * * 0 su uucp < /usr/lib/uucp/uudemon.wk + +...or like this: + + 5 * * * * echo /usr/lib/uucp/uudemon.hr | su uucp + 10 4 * * * echo /usr/lib/uucp/uudemon.day | su uucp + 15 5 * * 0 echo /usr/lib/uucp/uudemon.wk | su uucp + +On 4.3, they'd look a little bit better, but not much: + + 5 * * * * uucp /usr/lib/uucp/uudemon.hr + 10 4 * * * uucp /usr/lib/uucp/uudemon.day + 15 5 * * 0 uucp /usr/lib/uucp/uudemon.wk + +For this cron, you'd create /usr/lib/uucp/crontab.src (or wherever you want +to keep uucp's commands) which would look like this: + + # /usr/lib/uucp/crontab.src - uucp's crontab + # + PATH=/usr/lib/uucp:/bin:/usr/bin + SHELL=/bin/sh + HOME=/usr/lib/uucp + # + 5 * * * * uudemon.hr + 10 4 * * * uudemon.day + 15 5 * * 0 uudemon.wk + +The application to the `news' cron commands (if any) is left for you to +figure out. Likewise if there are any other cruddy-looking 'su' commands in +your crontab commands, you don't need them anymore: just find a good place +to put the `crontab.src' (or whatever you want to call it) file for that +user, put the cron commands into it, and install it using the `crontab' +command (probably with "-u USERNAME", but see the man page). + +If you run a 4.2-derived cron, you could of course just install your current +crontab in toto as root's crontab. It would work exactly the way your +current one does, barring the extra steps in installing or changing it. +There would still be advantages to this cron, mostly that you get mail if +there is any output from your cron commands. + +One note about getting mail from cron: you will probably find, after you +install this version of cron, that your cron commands are generating a lot +of irritating output. The work-around for this is to redirect all EXPECTED +output to a per-execution log file, which you can examine if you want to +see the output from the "last time" a command was executed; if you get any +UNEXPECTED output, it will be mailed to you. This takes a while to get +right, but it's amazingly convenient. Trust me. + diff --git a/usr.sbin/cron/doc/FEATURES b/usr.sbin/cron/doc/FEATURES new file mode 100644 index 000000000000..71b1486a8e01 --- /dev/null +++ b/usr.sbin/cron/doc/FEATURES @@ -0,0 +1,83 @@ + +Features of Vixie's cron relative to BSD 4.[23] and SysV crons: + +-- Environment variables can be set in each crontab. SHELL, USER, + LOGNAME, and HOME are set from the user's passwd entry; all except + USER can be changed in the crontab. PATH is especially useful to + set there. TZ can be set, but cron ignores it other than passing + it on through to the commands it runs. Format is + + variable=value + + Blanks surrounding the '=' will be eaten; other blanks in value are + okay. Leading or trailing blanks can be preserved by quoting, single + or double quotes are okay, just so they match. + + PATH=.:/bin:/usr/bin + SHELL=/bin/sh + FOOBAR = this is a long blanky example + + Above, FOOBAR would get "this is a long blanky example" as its value. + + SHELL and HOME will be used when it's time to run a command; if + you don't set them, HOME defaults to your /etc/passwd entry + and SHELL defaults to /bin/sh. + + MAILTO, if set to the login name of a user on your system, will be the + person that cron mails the output of commands in that crontab. This is + useful if you decide on BINMAIL when configuring cron.h, since binmail + doesn't know anything about aliasing. + +-- Weekdays can be specified by name. Case is not significant, but only + the first three letters should be specified. + +-- Months can likewise be specified by name. Three letters only. + +-- Ranges and lists can be mixed. Standard crons won't allow '1,3-5'. + +-- Ranges can specify 'step' values. '10-16/2' is like '10,12,14,16'. + +-- Sunday is both day 0 and day 7 -- apparently BSD and ATT disagree + about this. + +-- Each user gets their own crontab file. This is a win over BSD 4.2, + where only root has one, and over BSD 4.3, where they made the crontab + format incompatible and although the commands can be run by non-root + uid's, root is still the only one who can edit the crontab file. This + feature mimics the SysV cron. + +-- The 'crontab' command is loosely compatible with SysV, but has more + options which just generally make more sense. Running crontab with + no arguments will print a cute little summary of the command syntax. + +-- Comments and blank lines are allowed in the crontab file. Comments + must be on a line by themselves; leading whitespace is ignored, and + a '#' introduces the comment. + +-- (big win) If the `crontab' command changes anything in any crontab, + the 'cron' daemon will reload all the tables before running the + next iteration. In some crons, you have to kill and restart the + daemon whenever you change a crontab. In other crons, the crontab + file is reread and reparsed every minute even if it didn't change. + +-- In order to support the automatic reload, the crontab files are not + readable or writable except by 'crontab' or 'cron'. This is not a + problem, since 'crontab' will let you do pretty much whatever you + want to your own crontab, or if you are root, to anybody's crontab. + +-- If any output is generated by a command (on stdout OR stderr), it will + be mailed to the owner of the crontab that contained the command (or + MAILTO, see discussion of environment variables, above). The headers + of the mail message will include the command that was run, and a + complete list of the environment that was passed to it, which will + contain (at least) the USER (LOGNAME on SysV), HOME, and SHELL. + +-- the dom/dow situation is odd. '* * 1,15 * Sun' will run on the + first and fifteenth AND every Sunday; '* * * * Sun' will run *only* + on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this + is why we keep 'e->dow_star' and 'e->dom_star'. I didn't think up + this behaviour; it's how cron has always worked but the documentation + hasn't been very clear. I have been told that some AT&T crons do not + act this way and do the more reasonable thing, which is (IMHO) to "or" + the various field-matches together. In that sense this cron may not + be completely similar to some AT&T crons. diff --git a/usr.sbin/cron/doc/INSTALL b/usr.sbin/cron/doc/INSTALL new file mode 100644 index 000000000000..326be482dd71 --- /dev/null +++ b/usr.sbin/cron/doc/INSTALL @@ -0,0 +1,91 @@ +/* Copyright 1993,1994 by Paul Vixie + * All rights reserved + */ + +/* + * Copyright (c) 1997 by Internet Software Consortium + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS + * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE + * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL + * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR + * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS + * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS + * SOFTWARE. + */ + +$Id: INSTALL,v 1.2 1998/08/14 00:32:35 vixie Exp $ + +Read the comments at the top of the Makefile, then edit the area marked +'configurable stuff'. + +Edit config.h. The stuff I expect you to change is down a bit from the +top of the file, but it's clearly marked. Also look at pathnames.h. + +You don't have to create the /var/cron or /var/cron/tabs directories, since +both the daemon and the `crontab' program will do this the first time they +run if they don't exist. You do need to have a /var, though -- just "mkdir +/var" if you don't have one, or you can "mkdir /usr/var; ln -s /usr/var /var" +if you expect your /var to have a lot of stuff in it. + +You will also need /usr/local/etc and /usr/local/bin directories unless you +change the Makefile. These will have to be created by hand, but if you are +a long-time Usenet user you probably have them already. /usr/local/man is +where I keep my man pages, but I have the source for `man' and you probably +do not. Therefore you may have to put the man pages into /usr/man/manl, +which will be hard since there will be name collisions. (Note that the man +command was originally written by Bill Joy before he left Berkeley, and it +contains no AT&T code, so it is in UUNET's archive of freely-distributable +BSD code.) + +LINUX note: /usr/include/paths.h on some linux systems shows _PATH_SENDMAIL + to be /usr/bin/sendmail even though sendmail is installed in /usr/lib. + you should check this out. + +say: + make all + +su and say: + make install + +Note that if I can get you to "su and say" something just by asking, you have +a very serious security problem on your system and you should look into it. + +Edit your /usr/lib/crontab file into little pieces -- see the CONVERSION file +for help on this. + +Use the `crontab' command to install all the little pieces you just created. +Some examples (see below before trying any of these!) + + crontab -u uucp -r /usr/lib/uucp/crontab.src + crontab -u news -r /usr/lib/news/crontab.src + crontab -u root -r /usr/adm/crontab.src + +Notes on above examples: (1) the .src files are copied at the time the +command is issued; changing the source files later will have no effect until +they are reinstalled with another `crontab -r' command. (2) The crontab +command will affect the crontab of the person using the command unless `-u +USER' is given; `-u' only works for root. When using most `su' commands +under most BSD's, `crontab' will still think of you as yourself even though +you may think of yourself as root -- so use `-u' liberally. (3) the `-r' +option stands for `replace'; check the man page for crontab(1) for other +possibilities. + +Kill your existing cron daemon -- do `ps aux' and look for /etc/cron. + +Edit your /etc/rc or /etc/rc.local, looking for the line that starts up +/etc/cron. Comment it out and add a line to start the new cron daemon +-- usually /usr/local/etc/cron, unless you changed it in the Makefile. + +Start up this cron daemon yourself as root. Just type /usr/local/etc/cron +(or whatever); no '&' is needed since the daemon forks itself and the +process you executed returns immediately. + +ATT notes: for those people unfortunate enough to be stuck on a AT&T UNIX, +you will need the public-domain "libndir", found in the B News source and in +any comp.sources.unix archive. You will also need to hack the code some. diff --git a/usr.sbin/cron/doc/MAIL b/usr.sbin/cron/doc/MAIL new file mode 100644 index 000000000000..149e5527171c --- /dev/null +++ b/usr.sbin/cron/doc/MAIL @@ -0,0 +1,473 @@ +[ this is really old mail that came to me in response to my 1986 posting + to usenet asking for feature suggestions before releasing the first + version of cron. it is presented here for its entertainment value. + --vix ] + +From ptsfa!lll-crg!ames!acornrc!bob Wed Dec 31 10:07:08 1986 +Date: Wed, 31 Dec 86 08:59:31 pst +From: lll-crg!ames!acornrc!bob (Bob Weissman) +To: ptsfa!vixie!paul +Status: RO + +Sure, here's a suggestion: I'd like to be able to run a program, say, +every two hours. Current cron requires me to write +0,2,4,6,8,10,12,14,16,18,20,22 in the hours field. How about a notation +to handle this more elegantly? + +<< Okay, I've allowed 0-22/2 as a means of handling this. + The time specification for my cron is as follows: + specification = range {"," range} + range = (start "-" finish ["/" step]) | single-unit + This allows "1,3,5-7", which the current cron doesn't (it won't + do a range inside a list), and handles your specific need. >> + +From drw@mit-eddie Wed Dec 31 18:25:27 1986 +Date: Wed, 31 Dec 86 14:28:19 est +From: drw@mit-eddie (Dale Worley) +To: mit-eddie!vixie!paul +Status: RO + +We have a lot of lines in our crontab of the form + + 00 12 * * * su user < /usr/users/user/script.file + +This barfs (silently!) on our system (Dec Ultrix 1.2 == 4.2bsd) if +user's shell is csh. This, I am told, is because csh requires that +the environment be set up in certain ways, which cron doesn't do. +(Actually, I believe, it is because /etc/rc, which runs cron, doesn't +set up the environment enough for csh to run, and cron just inherits +the situation.) Anyway, the point is that if you find out what csh +really needs in its environment, you might want to set up cron to +provide some reasonable defaults (if it isn't supplied by cron's +parent). Also, could you tell me what csh needs, if you find out, so +we can hack our /etc/rc? + +<< well, the environment IS a problem. processes that cron forks + will inherit the environment of the person who ran the cron + daemon... I plan to edit out such useless things as TERMCAP, + TERM, and the like; supply correct values for HOME, USER, CWD, + and whatever else comes to mind. I'll make sure csh works... >> +From ptsfa!ames!seismo!dgis!generous Thu Jan 1 07:33:17 1987 +Date: Thu Jan 1 10:29:20 1987 +From: ames!seismo!dgis!generous (Curtis Generous) +To: nike!ptsfa!vixie!paul +Status: RO + +Paul: + +One of the limitations of the present versions of cron is the lack +of the capability of specifying a way to execute a command every +n units of time. + +Here is a good example: + +# Present method to start up uucico +02,12,22,32,42,52 * * * * exec /usr/lib/uucp/uucico -r1 + +# New method ?? (the ':' here is just one possibility for syntax) +02:10 * * * * exec /usr/lib/uucp/uucico -r1 + +This method would prove very helpful for those programs that get started +every few minutes, making the entry long and not easily readable. The first +number would specify the base time, and the second number the repetition +interval. + +<< Good idea, but bob@acornrc beat you to it. I used '/' instead of + ':'. This is my personal preference, and seems intuitive when you + think of the divide operator in C... Does anyone have a preference? >> + +From ptsfa!lll-lcc!seismo!decuac!c3pe!c3engr!charles Thu Jan 1 17:04:24 1987 +From: lll-lcc!seismo!c3pe!c3engr!charles (Charles Green) +To: c3pe!decuac!dolqci!vrdxhq!seismo!lll-lcc!ptsfa!vixie!paul +Date: Thu Jan 1 19:22:47 1987 +Status: RO + +Well, this isn't a compatible extension, but I have in times past wondered +about a facility to let you start a process at intervals of, say, 17 minutes, +instead of particular minutes out of each hour. + +<< This was a popular request! >> + +From seismo!uwvax!astroatc!nicmad!norvax!mann Sun Jan 4 13:04:01 1987 +Date: Fri, 2 Jan 87 09:23:53 cst +From: lll-lcc!seismo!uwvax!astroatc!nicmad!norvax!mann (Tom Mann) +To: ptsfa!vixie!paul +Status: RO + +I'm not sure if it is in cron (either SysV or BSD ... if it is, I haven't +figured it out ) but a comment feature would SURE BE NICE!. +There are times when I want to comment out an entry +for a period of time; it might also make it a lot more legible. + +<< My cron allows blank lines and standard #-type comments. I know + that one BSD4.2 cron I've used had it. I don't know about SysV. >> + +From ptsfa!hoptoad!hugh Mon Jan 5 10:26:46 1987 +Date: Mon, 5 Jan 87 01:22:17 PST +From: hoptoad!hugh (Hugh Daniel) +To: ptsfa!vixie!paul +Status: RO + + Hi, I do have a BIG one that I would like. I want to log ALL output +from command lines into a file for each line. Thus I might have a chance +of finding out why my crontab entry did not work. + This would seem to work best if done by cron, as it is now I have a google +of shell scripts laying about just to put the error output where I can see +it. + +<< My cron (and the SysV cron) will send mail to the owner of the + particular crontab file if a command generates any output on stdout + or stderr. This can be irritating, but if you write a script such + that any output means a problem occurred, you can avoid most logfile + needs, and not generate mail except in unforeseen circumstances. >> + +From ptsfa!dual!ucbvax!ihnp4!anvil!es!Robert_Toxen Mon Jan 5 13:08:46 1987 +From: dual!ucbvax!ihnp4!anvil!es!Robert_Toxen +Date: Fri, 2 Jan 87 14:25:29 EST +To: anvil!ihnp4!ucbvax!dual!ptsfa!vixie!paul +Status: RO + +Here are some suggestions: +1. Run it through the C preprocessor via "/lib/<whatever>". + +<< hmmm. this seems of limited utility, and if you really wanted + to do it that way, you could do it yourself (since users can + write to their own crontab files). I'll add '-' (read stdin) + to the crontab installer program to facilitate this. >> + +2. Allow specifying every Nth day of week, i.e., every second Wednesday. + I did this to calendar by separating the day of week (Wed=4, which one + to start on and N with slashes). I took modulo the day of year as a + starting point so that someone with a desk calendar documenting such + things can easily determine the offset (second number). I did this + while at SGI; alas I don't have a copy of the code. + +<< I can see how this could be useful, but I'm not sure how I'd + implement it. Cron currently doesn't keep track of the last time + a given command was run; whether the current Wednesday is the first + or second since the command was last run would be pretty hard to + figure out. I'd have to keep a database of commands and their + execution around, and purge it when the crontab was overwritten. + This is too much work for me, but if someone adds it, let me know. >> + +From ptsfa!ames!seismo!cbmvax!devon!paul Tue Jan 6 05:50:17 1987 +From: ames!seismo!cbmvax!devon!paul +To: cbmvax!seismo!nike!ptsfa!vixie!paul +Date: Mon Jan 5 09:29:57 1987 +Status: RO + +One problem that has always plagued me with cron is the assumed ORing. +I'd like to see some type of ANDing implemented. I guess I can best +describe this by example. Say I have the following line in my crontab +file: + +* * 4-31 * 1-6 /usr/bin/command + +What this does is run 'command' on the 4th thru 31st days of the +month, AND on Monday thru Saturday; which probably means running it +every day of the month (unless Sunday falls on days 1-3). This +happens because cron runs the command if the day-of-month OR the +day-of-week is true. + +What I'd like to happen with the above line is to run the command ONLY +on Monday thru Saturday any time after the 3rd of the month, e.g. if +the day-of-month AND the day-of-week are true. + +My proposal to you is to implement some special chars for the first +five fields. Examples: + +* * !1-3 * 1-6 /usr/bin/command + +(run command Mon-Sat, but NOT [!] on the first 3 days of the month) + +* * &4-31 * &1-6 /usr/bin/command + +(run command if day-of-month AND day-of-week are true) + +Get the picture? This would be compatible with existing versions of +cron (which wouldn't currently be using any special characters, so +that old crontabs would be handled correctly). + +<< This message made me aware of the actual boolean expression involved + in a crontab entry. I'd assumed that it was + (minute && hour && DoM && month && DoW) + But it's really + (minute && hour && month && (DoM || DoW)) + + I can see some value in changing this, but with a fixed order of + fields, operators get to be kindof unary, which && and || really + aren't. If someone has an idea on a syntax that allows useful + variations to the standard (&& && && (||)) default, please suggest. >> + +From bobkat!pedz Tue Jan 6 20:02:10 1987 +From: pedz@bobkat.UUCP (Pedz Thing) +Date: 2 Jan 87 17:34:44 GMT +Status: RO + +Log files! It would be nice to be able to specify a log for cron +itself and also a log for each program's stdout and stderr to go to. +The latter can of course be done with > and 2> but it would be nice if +there could be a single line with some sort of pattern like +`> /usr/spool/log/%' and the command would be substituted for the %. +Another thing which would be nice is to be able to specify which shell +to call to give the command to. + +<< Log files are done with mail. The '%' idea could be useful if + a different character were used (% is special to cron, see man + page); a different directory would have to be chosen, since each + user has their own crontab file; and something intelligent would + have to be done in the file naming, since the first word of the + command might be ambiguous (with other commands). In short, it's + too much work. Sorry. >> + +From guy%gorodish@sun Tue Jan 6 20:03:13 1987 +From: guy%gorodish@sun (Guy Harris) +Message-ID: <10944@sun.uucp> +Date: 5 Jan 87 12:09:09 GMT +References: <429@vixie.UUCP> <359@bobkat.UUCP> +Sender: news@sun.uucp +Status: RO + +> Another thing which would be nice is to be able to specify which shell +> to call to give the command to. + +Well, the obvious choice would be the user's shell, but this wouldn't work +for accounts like "uucico". + +<< I use the owning user's shell, and to handle "uucico" I check a + list of "acceptable shells" (currently compiled in, does anybody + mind?), substituting a default (compiled in) shell if the user's + shell isn't on the list. + + BTW, "compiled in" means that it's in a .h file, easily changed + during installation, but requiring recompilation to modify. You + don't have to go digging through the code to find it... >> + +From qantel!hplabs!ucbvax!mwm@violet.berkeley.edu Tue Jan 6 21:24:48 1987 +To: hplabs!qantel!vixie!paul (Paul Vixie Esq) +Date: 04 Jan 87 00:42:35 PST (Sun) +From: Mike Meyer <mwm@violet.berkeley.edu> +Status: RO + +<<[Discussion of RMS/FSF, and mwm's GNU Cron deleted]>> + +Oh, yeah - here are the extensions on my cron: + +1) Sunday is both day 0 and day 7, so it complies with both SysV and +BSD cron. + +<< Good idea. I did it too, thanks for informing me. >> + +2) At is integrated into the cron. Instead of atrun to scan the +/usr/spool/at directory, at files are put into the /usr/lib/cron +directory along with users cron files, and cron fabricates a line from +a crontab file to run them. This is considered a major win by all who +use it. + +<< I don't use 'at', and my cron doesn't do anything with it. To run + 'at', I use 'atrun' the same way the current BSD cron does. My + crontab files are in /usr/spool/cron/crontabs, in the SysV + tradition -- not in /usr/lib/cron. This is a configuration + parameter, of course. >> + +There are two known restrictions: + +1) I don't support any of the SysV security hooks. I don't have a use +for them, and RMS didn't like the idea at all :-). + +<< This means cron.allow and cron.deny. I plan to support them, as + they've been quite helpful at various HPUX sites I've administered. >> + +2) Cron expects to be able to create files with names longer than 14 +characters, which makes it hard to run on SysV. At least one person +was working on a port, but I don't know how it's going. That might +make for a good reason for releasing yours, right there. + +<< If someone has SysV (with the 14-character limit), they probably + won't want my cron, since it doesn't add much to the standard + version (which they may have support for). My cron is not currently + portable to non-BSD systems, since it relies on interval timers (I + needed to sleep for intervals more granular than seconds alone would + allow). The port would be trivial, and I will do it if a lot of + people ask for it... >> + +Oh, yeah - I'm going to see about getting this cron integrated into +the next 4BSD release. + +<< How does one go about this? I have a few nifty gadgets I'd like + to contribute, this cron being one of them... >> + +<<[more FSF/GNU discussion deleted]>> + +From qantel!hplabs!ames!ut-sally!ut-ngp!melpad!bigtex!james Tue Jan 6 21:24:57 1987 +Posted-Date: Fri, 2 Jan 87 19:26:16 est +Date: Fri, 2 Jan 87 19:26:16 est +From: hplabs!ames!ut-sally!ut-ngp!bigtex!james +To: vixie!paul +Status: RO + +Yes!!! There are several critical failures in System V cron... + +1. Pass all variables in cron's environment into the environment of things + cron starts up, or at least into the crontab entries started up (at jobs + will inherit the environment of the user). If nothing else it is critically + important that the TZ variable be passed on. PATH should be passed on too. + Basically, passing environment values allows one to design a standard + environment with TZ and PATH and have that run by everything. If anyone + tells you this is no big deal, consider what happens when uucico is + started by cron in CA to make a long distance phone link... Unless the + administrator is really on his/her toes, calls scheduled at 5pm will really + go at two in the afternoon, needlessly incurring huge phone bills, all + because System V refuses to pass the TZ from its environment down. There + are work arounds, but only putting it in cron will really work. This is + not a security hole. + +<< delete TERM and TERMCAP; modify HOME, USER, and CWD; pass TZ and + PATH through undisturbed. any other requests out there? + + BSD doesn't have this problem -- TZ is passed right on through if + you define it in the shell before starting my cron daemon. However, + the BSD I'm running this on doesn't need TZ to be defined anyway... + The default in the kernel has been just fine so far... But just the + same, if/when I port to SysV (I guess I really should), I'll make + sure this works right. + + I guess I've been spoiled. HPUX is SysV-based, and I never had a + problem with cron and TZ when I used it. >> + +2. A way to avoid logging stuff in /usr/lib/cron/log. I have a cron entry + run uudemon.hr every 10 minutes. This is 144 times/day. Each run generates + three lines of text, for a total of 432 lines of text I don't want to see. + Obviously this should be optional, but it would be nice if there were a + way to flag an entry so that it wasn't logged at all unless there was an + error. + +<< I don't know nothin' 'bout no /usr/lib/cron/log. What is this file? + I don't see any reason to create log entries, given the mail-the- + output behaviour. Opinions, anyone? >> + +I will come up with other ideas no doubt, but I can always implement them +myself. + +<< That's what I like about PD software. Please send me the diffs! >> + +The other problem you have is making sure you can run standard +crontabs. I would suggest something like this: if the command part of the +entry starts with an unescaped -, then flags and options follow immediately +thereafter. As in: + +2,12,22,32,42,52 * * * * -q /usr/lib/uucp/uudemon.hr + +This could mean do not log the uudemon.hr run unless there is a problem of +some kind. This is probably safe as not many filenames start with "-", and +those that do are already a problem for people. + +<< Since I don't plan on supporting /usr/lib/cron/log in ANY form unless + many people request it, I won't be needing -q as you've defined it. + I could use something like this to avoid sending mail on errors, for + the occasional script that you don't want to bullet-proof. + + The compatibility issue is CRITICAL. The 4.3BSD crontab format is + a crime against the whole philosophy of Unix(TM), in my opinion. >> + +One other minor thing to consider is the ulimit: can different users get +different ulimits for their crontab entries? + +<< Boy I'm ignorant today. What's a ulimit, and what should I do with + it in a crontab? Suggestions, enlightenment, etc ?? >> + +From qantel!lll-crg!ames!uw-beaver!uw-nsr!john Tue Jan 6 23:32:44 1987 +Date: Thu, 1 Jan 87 10:53:05 pst +From: lll-crg!ames!uw-beaver!uw-nsr!john (John Sambrook 5-7433) +To: vixie!paul +Status: RO + +How about not hardwiring the default environment that cron builds for its +children in the cron program itself? Our cron does this and it's the pits +because we are TZ=PST8PDT not TZ=EST5EDT ! + +<< yeachk. I assure you, I will not hardwire the TZ! >> +From ptsfa!well!dv Fri Jan 9 04:01:50 1987 +Date: Thu, 8 Jan 87 23:50:40 pst +From: well!dv (David W. Vezie) +To: ptsfa!vixie!paul +Status: RO + +6, have a special notation called 'H' which would expand to weekends + and holidays (you'd have to keep a database somewhere of real + holidays), and also 'W' for workdays (neither weekend or holiday). + +<< Too much work. There should be a standard way to define and + detect holidays under Unix(TM); if there were, I'd use it. As + it is, I'll leave this for someone else to add. + + I can see the usefulness; it just doesn't quite seem worth it. >> +From qantel!gatech!akgua!blnt1!jat Wed Jan 14 20:00:40 1987 +Date: Tue, 13 Jan 87 16:39:38 EST +From: gatech!akgua!blnt1!jat +Status: RO + +1) Add some way to tell cron to reread the files, say kill -1 <pid> + +<< whenever the 'crontab' program is run and updates a crontab file, + a file /usr/spool/cron/POKECRON is created; next time the cron + daemon wakes up, it sees it, and re-reads the crontab files. + + I thought of handling the signal; even implemented it. Then this + clever idea hit me and I ripped it all out and added a single + IF-statement to handle the POKECRON file. >> + +2) Have some kind of retry time so that if a command fails, cron will try to + execute it again after a certain period. This is useful if you have some + type of cleanup program that can run at the scheduled time for some reason + (such as locked device, unmounted filesystem, etc). + +<< Hmmm, sounds useful. I could do this by submitting an 'at' job... + I'll think about it. >> +From ptsfa!dual!ucbvax!ihnp4!mtuxo!ender Sat Jan 3 16:54:00 1987 +From: dual!ucbvax!ihnp4!mtuxo!ender +Date: Sat, 3 Jan 87 14:05:13 PST +To: ucbvax!dual!ptsfa!vixie!paul +Status: RO + +It would be nice if nonprivileged users can setup personal crontab files +(~/.cronrc, say) and be able to run personal jobs at regular intervals. + +<< this is done, but in the SysV style: the 'crontab' program installs + a new crontab file for the executing user (can be overridden by root + for setup of uucp and news). the advantage of this is that (1) when + a crontab is changed, the daemon can be informed automatically; and + (2) the file can be syntax-checked before installation. >> +From ptsfa!ames!seismo!ihnp4!lcc!richard Fri Jan 16 04:47:33 1987 +Date: Fri, 16 Jan 87 07:44:57 EST +To: nike!ptsfa!vixie!paul +Status: RO + +The System V cron is nice, but it has a few annoying features. One is that +its mail files will say that the previous message is the output of "one of your +cron commands." I wish it would say WHICH cron command. + +<< Done. Also which shell, which user (useful when the mail gets + forwarded), which home directory, and other useful crud. >> + +Another problem is with timezones. It is necessary to specify TZ=PST8PDT (or +whatever) when you invoke cron (from inittab, or /etc/rc) and it is also +necessary to add TZ=PST8PDT to each crontab line which might need it. Cron +should automatically export its idea of the "TZ" to each invoked command, and +it should be possible to put a line in the crontab file which overrides that +for every command in the file (e.g., most users are on EST, so cron is run +with TZ=EST5EDT; but one user is usually on PST and wants all of his cron +commands to run with TZ=PST8PDT). This might be extended to allow any +environment variable to be specified once for the whole crontab file (e.g., +PATH). + +<< Well, since I run the user's shell, you could put this into .cshrc. + generic environment-variable setting could be useful, though. Since + I have to modify the environment anyway, I'll consider this. >> + +A log file might be a nice idea, but the System V cron log is too verbose. +I seem to remember that cron keeps it open, too; so you can't even have +something go and periodically clean it out. + +<< I don't do /usr/lib/cron/log. I wasn't aware of this file until I + got all these suggestions. Do people want this file? Tell me! >> diff --git a/usr.sbin/cron/doc/Makefile.vixie b/usr.sbin/cron/doc/Makefile.vixie new file mode 100644 index 000000000000..53b8e9b9bcc5 --- /dev/null +++ b/usr.sbin/cron/doc/Makefile.vixie @@ -0,0 +1,124 @@ +#/* Copyright 1988,1990,1993,1994 by Paul Vixie +# * All rights reserved +# */ + +## Copyright (c) 1997 by Internet Software Consortium. +## +## Permission to use, copy, modify, and distribute this software for any +## purpose with or without fee is hereby granted, provided that the above +## copyright notice and this permission notice appear in all copies. +## +## THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS +## ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES +## OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE +## CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL +## DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR +## PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS +## ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +## SOFTWARE. + +# Makefile for vixie's cron +# +# $Id: Makefile,v 1.2 1998/08/14 00:32:35 vixie Exp $ +# +# vix 03mar88 [moved to RCS, rest of log is in there] +# vix 30mar87 [goodbye, time.c; hello, getopt] +# vix 12feb87 [cleanup for distribution] +# vix 30dec86 [written] + +# NOTES: +# 'make' can be done by anyone +# 'make install' must be done by root +# +# this package needs getopt(3), bitstring(3), and BSD install(8). +# +# the configurable stuff in this makefile consists of compilation +# options (use -O, cron runs forever) and destination directories. +# SHELL is for the 'augumented make' systems where 'make' imports +# SHELL from the environment and then uses it to run its commands. +# if your environment SHELL variable is /bin/csh, make goes real +# slow and sometimes does the wrong thing. +# +# this package needs the 'bitstring macros' library, which is +# available from me or from the comp.sources.unix archive. if you +# put 'bitstring.h' in a non-standard place (i.e., not intuited by +# cc(1)), you will have to define INCLUDE to set the include +# directory for cc. INCLUDE should be `-Isomethingorother'. +# +# there's more configuration info in config.h; edit that first! + +#################################### begin configurable stuff +#<<DESTROOT is assumed to have ./etc, ./bin, and ./man subdirectories>> +DESTROOT = $(DESTDIR)/usr +DESTSBIN = $(DESTROOT)/sbin +DESTBIN = $(DESTROOT)/bin +DESTMAN = $(DESTROOT)/share/man +#<<need bitstring.h>> +INCLUDE = -I. +#INCLUDE = +#<<need getopt()>> +LIBS = +#<<optimize or debug?>> +#CDEBUG = -O +CDEBUG = -g +#<<lint flags of choice?>> +LINTFLAGS = -hbxa $(INCLUDE) $(DEBUGGING) +#<<want to use a nonstandard CC?>> +CC = gcc -Wall -Wno-unused -Wno-comment +#<<manifest defines>> +DEFS = +#(SGI IRIX systems need this) +#DEFS = -D_BSD_SIGNALS -Dconst= +#<<the name of the BSD-like install program>> +#INSTALL = installbsd +INSTALL = install +#<<any special load flags>> +LDFLAGS = +#################################### end configurable stuff + +SHELL = /bin/sh +CFLAGS = $(CDEBUG) $(INCLUDE) $(DEFS) + +INFOS = README CHANGES FEATURES INSTALL CONVERSION THANKS MAIL +MANPAGES = bitstring.3 crontab.5 crontab.1 cron.8 putman.sh +HEADERS = bitstring.h cron.h config.h pathnames.h externs.h +SOURCES = cron.c crontab.c database.c do_command.c entry.c \ + env.c job.c user.c popen.c misc.c +SHAR_SOURCE = $(INFOS) $(MANPAGES) Makefile $(HEADERS) $(SOURCES) +LINT_CRON = cron.c database.c user.c entry.c \ + misc.c job.c do_command.c env.c popen.c +LINT_CRONTAB = crontab.c misc.c entry.c env.c +CRON_OBJ = cron.o database.o user.o entry.o job.o do_command.o \ + misc.o env.o popen.o +CRONTAB_OBJ = crontab.o misc.o entry.o env.o + +all : cron crontab + +lint : + lint $(LINTFLAGS) $(LINT_CRON) $(LIBS) \ + |grep -v "constant argument to NOT" 2>&1 + lint $(LINTFLAGS) $(LINT_CRONTAB) $(LIBS) \ + |grep -v "constant argument to NOT" 2>&1 + +cron : $(CRON_OBJ) + $(CC) $(LDFLAGS) -o cron $(CRON_OBJ) $(LIBS) + +crontab : $(CRONTAB_OBJ) + $(CC) $(LDFLAGS) -o crontab $(CRONTAB_OBJ) $(LIBS) + +install : all + $(INSTALL) -c -m 111 -o root -s cron $(DESTSBIN)/ + $(INSTALL) -c -m 4111 -o root -s crontab $(DESTBIN)/ + sh putman.sh crontab.1 $(DESTMAN) + sh putman.sh cron.8 $(DESTMAN) + sh putman.sh crontab.5 $(DESTMAN) + +clean :; rm -f *.o cron crontab a.out core tags *~ #* + +tags :; ctags ${SOURCES} + +kit : $(SHAR_SOURCE) + makekit -m -s99k $(SHAR_SOURCE) + +$(CRON_OBJ) : cron.h config.h externs.h pathnames.h Makefile +$(CRONTAB_OBJ) : cron.h config.h externs.h pathnames.h Makefile diff --git a/usr.sbin/cron/doc/README b/usr.sbin/cron/doc/README new file mode 100644 index 000000000000..ebd8849a52a0 --- /dev/null +++ b/usr.sbin/cron/doc/README @@ -0,0 +1,68 @@ +#/* Copyright 1988,1990,1993 by Paul Vixie <paul@vix.com> +# * All rights reserved +# */ + +## Copyright (c) 1997 by Internet Software Consortium. +## +## Permission to use, copy, modify, and distribute this software for any +## purpose with or without fee is hereby granted, provided that the above +## copyright notice and this permission notice appear in all copies. +## +## THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS +## ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES +## OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE +## CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL +## DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR +## PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS +## ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +## SOFTWARE. + +Vixie Cron V4.0 - September 7, 1997 +[V3.1 was some time after 1993] +[V3.0 was December 27, 1993] +[V2.2 was some time in 1992] +[V2.1 was May 29, 1991] +[V2.0 was July 5, 1990] +[V2.0-beta was December 9, 1988] +[V1.0 was May 6, 1987] +Paul Vixie + +This is a version of 'cron' that is known to run on most systems. It +is functionally based on the SysV cron, which means that each user can have +their own crontab file (all crontab files are stored in a read-protected +directory, usually /var/cron/tabs). No direct support is provided for +'at'; you can continue to run 'atrun' from the crontab as you have been +doing. If you don't have atrun (i.e., System V) you are in trouble. + +A messages is logged each time a command is executed; also, the files +"allow" and "deny" in /var/cron can be used to control access to the +"crontab" command (which installs crontabs). It hasn't been tested on +SysV, although some effort has gone into making the port an easy one. + +To use this: Sorry, folks, there is no cutesy 'Configure' script. You'll +have to go edit a couple of files... So, here's the checklist: + + Read all the FEATURES, INSTALL, and CONVERSION files + Edit config.h + Edit Makefile + (both of these files have instructions inside; note that + some things in config.h are definable in Makefile and are + therefore surrounded by #ifndef...#endif) + 'make' + 'su' and 'make install' + (you may have to install the man pages by hand) + kill your existing cron process + (actually you can run your existing cron if you want, but why?) + build new crontabs using /usr/lib/{crontab,crontab.local} + (either put them all in "root"'s crontab, or divide it up + and rip out all the 'su' commands, collapse the lengthy + lists into ranges with steps -- basically, this step is + as much work as you want to make it) + start up the new cron + (must be done as root) + watch it. test it with 'crontab -r' and watch the daemon track your + changes. + if you like it, change your /etc/{rc,rc.local} to use it instead of + the old one. + +$Id: README,v 1.2 1998/08/14 00:32:35 vixie Exp $ diff --git a/usr.sbin/cron/doc/README.1ST b/usr.sbin/cron/doc/README.1ST new file mode 100644 index 000000000000..66cd0b237bd2 --- /dev/null +++ b/usr.sbin/cron/doc/README.1ST @@ -0,0 +1,4 @@ +Sources substantially rearranged 26 Aug 94, Jordan Hubbard. Content +remains faithful to the original 3.0 cron source from Paul Vixie, but +any bugs introduced by this reorganization or the port to FreeBSD remain +purely my own. - Jordan diff --git a/usr.sbin/cron/doc/THANKS b/usr.sbin/cron/doc/THANKS new file mode 100644 index 000000000000..3787c2943d7a --- /dev/null +++ b/usr.sbin/cron/doc/THANKS @@ -0,0 +1,29 @@ +15 January 1990 +Paul Vixie + +Many people have contributed to cron. Many more than I can remember, in fact. +Rich Salz and Carl Gutekunst were each of enormous help to me in V1; Carl for +helping me understand UNIX well enough to write it, and Rich for helping me +get the features right. + +John Gilmore wrote me a wonderful review of V2, which took me a whole year to +answer even though it made me clean up some really awful things in the code. +(According to John the most awful things are still in here, of course.) + +Paul Close made a suggestion which led to /etc/crond.pid and the mutex locking +on it. Kevin Braunsdorf of Purdue made a suggestion that led to @reboot and +its brothers and sisters; he also sent some diffs that lead cron toward compil- +ability with System V, though without at(1) capabilities, this cron isn't going +to be that useful on System V. Bob Alverson fixed a silly bug in the line +number counting. Brian Reid made suggestions which led to the run queue and +the source-file labelling in installed crontabs. + +Scott Narveson ported V2 to a Sequent, and sent in the most useful single batch +of diffs I got from anybody. Changes attributable to Scott are: + -> sendmail won't time out if the command is slow to generate output + -> day-of-week names aren't off by one anymore + -> crontab says the right thing if you do something you shouldn't do + -> crontab(5) man page is longer and more informative + -> misc changes related to the side effects of fclose() + -> Sequent "universe" support added (may also help on Pyramids) + -> null pw_shell is dealt with now; default is /bin/sh |