Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Clean up deleted files.

Browse Source
This commit is contained in:
mycroft 1994-01-05 20:52:52 +00:00
parent 644d4f8787
commit 22183f4e79
9 changed files with 0 additions and 1212 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

149
libexec/cron/CHANGES
View File

@ -1,149 +0,0 @@
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 interrim 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 interrim 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. Sorry, NeXT users -- pray for POSIX. Irving also
asked for a per-job MAILTO, but the syntactic overkill that would require is more
than I'm willing to add. Remember, on BSD4.2, cron was a 12K daemon. My cron is
about ten times that size already.
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)

85
libexec/cron/CONVERSION
View File

@ -1,85 +0,0 @@
$Id: CONVERSION,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $
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 seperate 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.

88
libexec/cron/FEATURES
View File

@ -1,88 +0,0 @@
$Id: FEATURES,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $
Features of Vixie's cron relative to BSD 4.[23] and SysV crons:
-- Environment variables can be set in each crontab. SHELL, USER,
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 examined when it's time to run a command; if
you don't change them, they default to your /etc/passwd entry.
*DANGER*, WILL ROBINSON! This means that all 'uucp' logins should set
SHELL=/bin/sh or cron will try to use /usr/lib/uucp/uucico as the
shell. This won't work.
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.
Setting SHELL=/bin/sh will in general speed up your commands since it
is a much smaller shell than the one you probably use normally (csh
or ksh) and has enough features to work non-interactively.
-- 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, it
tells the 'cron' daemon, who reloads 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.

475
libexec/cron/MAIL
View File

@ -1,475 +0,0 @@
[ 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 ]
$Id: MAIL,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $
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 compatable 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 commmand.
<< 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! >>

30
libexec/cron/MANIFEST
View File

@ -1,30 +0,0 @@
File Name Archive # Description
-----------------------------------------------------------
CHANGES 1
CONVERSION 1
FEATURES 1
INSTALL 1
MAIL 2
MANIFEST 1 This shipping list
Makefile 1
README 1
THANKS 1
bitstring.3 1
bitstring.h 1
config.h 1
cron.8 1
cron.c 1
cron.h 1
crontab.1 1
crontab.5 1
crontab.c 2
database.c 1
do_command.c 2
entry.c 2
env.c 1
externs.h 1
job.c 1
misc.c 2
pathnames.h 1
popen.c 1
user.c 1

72
libexec/cron/README
View File

@ -1,72 +0,0 @@
#/* Copyright 1988,1990,1993 by Paul Vixie
# * All rights reserved
# *
# * Distribute freely, except: don't remove my name from the source or
# * documentation (don't take credit for my work), mark your changes (don't
# * get me blamed for your possible bugs), don't alter or remove this
# * notice. May be sold if buildable source is provided to buyer. No
# * warrantee of any kind, express or implied, is included with this
# * software; use at your own risk, responsibility for damages (if any) to
# * anyone resulting from the use of this software rests entirely with the
# * user.
# *
# * Send bug reports, bug fixes, enhancements, requests, flames, etc., and
# * I'll try to keep a version up to date. I can be reached as follows:
# * Paul Vixie <paul@vix.com> uunet!decwrl!vixie!paul
# */
Vixie Cron V3.0
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 BSD 4.[23] 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.
This is more or less the copyright that USENET contributed software usually
has. Since ATT couldn't use this version if they had to freely distribute
source, and since I'd love to see them use it, I'll offer some rediculously
low license fee just to have them take it. In the unlikely event that they
do this, I will continue to support and distribute the pseudo-PD version, so
please, don't flame me for wanting my work to see a wider distribution.
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.1.1.1 1994/01/05 20:40:12 jtc Exp $

168
libexec/cron/bitstring.3
View File

@ -1,168 +0,0 @@
.\" Copyright (c) 1989 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" This code is derived from software contributed to Berkeley by
.\" Paul Vixie.
.\"
.\" Redistribution and use in source and binary forms are permitted
.\" provided that the above copyright notice and this paragraph are
.\" duplicated in all such forms and that any documentation,
.\" advertising materials, and other materials related to such
.\" distribution and use acknowledge that the software was developed
.\" by the University of California, Berkeley. The name of the
.\" University may not be used to endorse or promote products derived
.\" from this software without specific prior written permission.
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.\" @(#)bitstring.3 5.1 (Berkeley) 12/13/89
.\"
.TH BITSTRING 3 "December 13, 1989"
.UC 4
.SH NAME
bit_alloc, bit_clear, bit_decl, bit_ffs, bit_nclear, bit_nset,
bit_set, bitstr_size, bit_test \- bit-string manipulation macros
.SH SYNOPSIS
.ft B
.nf
#include <bitstring.h>
name = bit_alloc(nbits)
bitstr_t *name;
int nbits;
bit_decl(name, nbits)
bitstr_t name;
int nbits;
bit_clear(name, bit)
bitstr_t name;
int bit;
bit_ffc(name, nbits, value)
bitstr_t name;
int nbits, *value;
bit_ffs(name, nbits, value)
bitstr_t name;
int nbits, *value;
bit_nclear(name, start, stop)
bitstr_t name;
int start, stop;
bit_nset(name, start, stop)
bitstr_t name;
int start, stop;
bit_set(name, bit)
bitstr_t name;
int bit;
bitstr_size(nbits)
int nbits;
bit_test(name, bit)
bitstr_t name;
int bit;
.fi
.ft R
.SH DESCRIPTION
These macros operate on strings of bits.
.PP
.I Bit_alloc
returns a pointer of type
.I bitstr_t\ *
to sufficient space to store
.I nbits
bits, or NULL if no space is available.
.PP
.I Bit_decl
is a macro for allocating sufficient space to store
.I nbits
bits on the stack.
.PP
.I Bitstr_size
returns the number of elements of type
.I bitstr_t
necessary to store
.I nbits
bits.
This is useful for copying bit strings.
.PP
.I Bit_clear
and
.I bit_set
clear or set the zero-based numbered bit
.IR bit ,
in the bit string
.IR name .
.PP
.I Bit_nset
and
.I bit_nclear
set or clear the zero-based numbered bits from
.I start
to
.I stop
in the bit string
.IR name .
.PP
.I Bit_test
evaluates to zero if the zero-based numbered bit
.I bit
of bit string
.I name
is set, and non-zero otherwise.
.PP
.I Bit_ffs
sets
.I *value
to the zero-based number of the first bit set in the array of
.I nbits
bits referenced by
.IR name .
If no bits are set,
.I *value
is set to -1.
.PP
.I Bit_ffc
sets
.I *value
to the zero-based number of the first bit not set in the array of
.I nbits
bits referenced by
.IR name .
If all bits are set,
.I value
is set to -1.
.SH EXAMPLE
.nf
.in +5
#include <limits.h>
#include <bitstring.h>
...
#define LPR_BUSY_BIT 0
#define LPR_FORMAT_BIT 1
#define LPR_DOWNLOAD_BIT 2
...
#define LPR_AVAILABLE_BIT 9
#define LPR_MAX_BITS 10
make_lpr_available()
{
bitstr_t bit_decl(bitlist, LPR_MAX_BITS);
...
bit_nclear(bitlist, 0, LPR_MAX_BITS - 1);
...
if (!bit_test(bitlist, LPR_BUSY_BIT)) {
bit_clear(bitlist, LPR_FORMAT_BIT);
bit_clear(bitlist, LPR_DOWNLOAD_BIT);
bit_set(bitlist, LPR_AVAILABLE_BIT);
}
}
.fi
.SH "SEE ALSO"
malloc(3)

122
libexec/cron/bitstring.h
View File

@ -1,122 +0,0 @@
/*
* Copyright (c) 1989 The Regents of the University of California.
* All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Paul Vixie.
*
* Redistribution and use in source and binary forms are permitted
* provided that the above copyright notice and this paragraph are
* duplicated in all such forms and that any documentation,
* advertising materials, and other materials related to such
* distribution and use acknowledge that the software was developed
* by the University of California, Berkeley. The name of the
* University may not be used to endorse or promote products derived
* from this software without specific prior written permission.
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*
* @(#)bitstring.h 5.2 (Berkeley) 4/4/90
*/
typedef unsigned char bitstr_t;
/* internal macros */
/* byte of the bitstring bit is in */
#define _bit_byte(bit) \
((bit) >> 3)
/* mask for the bit within its byte */
#define _bit_mask(bit) \
(1 << ((bit)&0x7))
/* external macros */
/* bytes in a bitstring of nbits bits */
#define bitstr_size(nbits) \
((((nbits) - 1) >> 3) + 1)
/* allocate a bitstring */
#define bit_alloc(nbits) \
(bitstr_t *)malloc(1, \
(unsigned int)bitstr_size(nbits) * sizeof(bitstr_t))
/* allocate a bitstring on the stack */
#define bit_decl(name, nbits) \
(name)[bitstr_size(nbits)]
/* is bit N of bitstring name set? */
#define bit_test(name, bit) \
((name)[_bit_byte(bit)] & _bit_mask(bit))
/* set bit N of bitstring name */
#define bit_set(name, bit) \
(name)[_bit_byte(bit)] |= _bit_mask(bit)
/* clear bit N of bitstring name */
#define bit_clear(name, bit) \
(name)[_bit_byte(bit)] &= ~_bit_mask(bit)
/* clear bits start ... stop in bitstring */
#define bit_nclear(name, start, stop) { \
register bitstr_t *_name = name; \
register int _start = start, _stop = stop; \
register int _startbyte = _bit_byte(_start); \
register int _stopbyte = _bit_byte(_stop); \
if (_startbyte == _stopbyte) { \
_name[_startbyte] &= ((0xff >> (8 - (_start&0x7))) | \
(0xff << ((_stop&0x7) + 1))); \
} else { \
_name[_startbyte] &= 0xff >> (8 - (_start&0x7)); \
while (++_startbyte < _stopbyte) \
_name[_startbyte] = 0; \
_name[_stopbyte] &= 0xff << ((_stop&0x7) + 1); \
} \
}
/* set bits start ... stop in bitstring */
#define bit_nset(name, start, stop) { \
register bitstr_t *_name = name; \
register int _start = start, _stop = stop; \
register int _startbyte = _bit_byte(_start); \
register int _stopbyte = _bit_byte(_stop); \
if (_startbyte == _stopbyte) { \
_name[_startbyte] |= ((0xff << (_start&0x7)) & \
(0xff >> (7 - (_stop&0x7)))); \
} else { \
_name[_startbyte] |= 0xff << ((_start)&0x7); \
while (++_startbyte < _stopbyte) \
_name[_startbyte] = 0xff; \
_name[_stopbyte] |= 0xff >> (7 - (_stop&0x7)); \
} \
}
/* find first bit clear in name */
#define bit_ffc(name, nbits, value) { \
register bitstr_t *_name = name; \
register int _byte, _nbits = nbits; \
register int _stopbyte = _bit_byte(_nbits), _value = -1; \
for (_byte = 0; _byte <= _stopbyte; ++_byte) \
if (_name[_byte] != 0xff) { \
_value = _byte << 3; \
for (_stopbyte = _name[_byte]; (_stopbyte&0x1); \
++_value, _stopbyte >>= 1); \
break; \
} \
*(value) = _value; \
}
/* find first bit set in name */
#define bit_ffs(name, nbits, value) { \
register bitstr_t *_name = name; \
register int _byte, _nbits = nbits; \
register int _stopbyte = _bit_byte(_nbits), _value = -1; \
for (_byte = 0; _byte <= _stopbyte; ++_byte) \
if (_name[_byte]) { \
_value = _byte << 3; \
for (_stopbyte = _name[_byte]; !(_stopbyte&0x1); \
++_value, _stopbyte >>= 1); \
break; \
} \
*(value) = _value; \
}

23
libexec/cron/putman.sh
View File

@ -1,23 +0,0 @@
#!/bin/sh
# putman.sh - install a man page according to local custom
# vixie 27dec93 [original]
#
# $Id: putman.sh,v 1.1.1.1 1994/01/05 20:40:16 jtc Exp $
PAGE=$1
DIR=$2
SECT=`expr $PAGE : '[a-z]*.\([0-9]\)'`
[ -d $DIR/man$SECT ] && {
set -x
cp $PAGE $DIR/man$SECT/$PAGE
set +x
} || {
set -x
nroff -man $PAGE >$DIR/cat$SECT/`basename $PAGE .$SECT`.0
set +x
}
exit 0