mail

source code of crond

<<	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![e-mail] 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 <[e-mail]>
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!    >>