808a36ef65
This will make a number of things easier in the future, as well as (finally!) avoiding the Id-smashing problem which has plagued developers for so long. Boy, I'm glad we're not using sup anymore. This update would have been insane otherwise.
476 lines
20 KiB
Plaintext
476 lines
20 KiB
Plaintext
[ 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 ]
|
|
|
|
$FreeBSD$
|
|
|
|
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! >>
|