cron(1m) facility incl at(1) batch(1) crontab(1) part 1 of 4

Donald Lashomb donlash at uncle.uucp
Mon Jan 14 09:57:53 AEST 1991


Here is the newest version of my cron(1M) facility.  This version fixes
the getwd() bug in my previous version, adds a new option and generally
is a cleaner implementation than the old version.

Cron(1M) is a facility that allows you to schedule jobs that will be
executed at a later time.  It includes the at(1), batch(1) and [user]
crontab(1) commands which are available on many unix systems, but not
the AT&T UNIX-pc; so I wrote my own.

Some highlights:

	*  the ability to specify a nice value, even neg for root

	*  great variety of listing options

	*  accepts names like Sun Mon etc in times, dates, schedules

	*  security strictly enforced by real uid

	*  new cronjob command runs like at(1), but repetitively like
	   crontab.  I use this instead of crontab, it's more efficient.

	*  crtabj command is what really does crontab

	*  everything (almost) compatable with standard sysV versions

This cron facility was written for the AT&T Unix-PC model 7300.  I believe
it should port well to other sysV machines.  How well it will port to BSD
machines, I don't know.

---
Donald Lashomb			donlash at uncle.UUCP
Cranberry Lake, NY		...!uncle!crlake!{install root donny}

---- Cut Here and unpack ----
#!/bin/sh
# This is a shell archive (shar 3.21)
# made 10/25/1990 21:37 UTC by install at crlake
# Source directory /u/install/Filecabinet/src/cron
#
# existing files will NOT be overwritten
#
# This shar contains:
# length  mode       name
# ------ ---------- ------------------------------------------
#  19046 -rw-r--r-- Design_Notes
#   4358 -rw-r--r-- Examples
#    244 -rw-r--r-- Files
#   7286 -rwxr--r-- Install
#     40 -rw-r--r-- Name
#  17482 -rw-r--r-- README
#    882 -rwxr--r-- Remove
#      4 -rw-r--r-- Size
#  15142 -rw-r--r-- at.1
#  22541 -rw-r--r-- at.c
#   2275 -rw-r--r-- convertjob.c
#   7418 -rw-r--r-- cron.1
#   4499 -rw-r--r-- cron.h
#   6593 -rw-r--r-- crontab.1
#   9025 -rw-r--r-- crontab.c
#  16055 -rw-r--r-- daemon.c
#    761 -rw-r--r-- dir.c
#   2253 -rw-r--r-- fifo.c
#   2096 -rw-r--r-- getwd.c
#    120 -rw-r--r-- job.c
#   4276 -rw-r--r-- job.h
#   2311 -rw-r--r-- log.c
#   2583 -rw-r--r-- login.c
#   1734 -rw-r--r-- makefile
#   4373 -rw-r--r-- memlist.c
#    475 -rw-r--r-- mkfifo.c
#   4523 -rw-r--r-- parsesched.c
#  10619 -rw-r--r-- parsetime.c
#   3496 -rw-r--r-- resched.c
#   4537 -rw-r--r-- version
#
if touch 2>&1 | fgrep '[-amc]' > /dev/null
 then TOUCH=touch
 else TOUCH=true
fi
# ============= Design_Notes ==============
if test X"$1" != X"-c" -a -f 'Design_Notes'; then
	echo "File already exists: skipping 'Design_Notes'"
else
echo "x - extracting Design_Notes (Text)"
sed 's/^X//' << 'SHAR_EOF' > Design_Notes &&
XCron Facility by Donald Lashomb
X
X
X===                                                                ===
X| The following notes were some of things that I was thinking during |
X| the design of the at(1) facility.  DON'T pay too much attention to |
X| them, many of the details were changed in the final design.        |
X===                                                                ===
X
XThis project is to build an at(1) facility for the unix-pc.
X
X[ wrote all my own code ]
X
XMy design for at(1) consists of basically two programs: a daemon that
Xruns all the time in the backaground, and a user-callable command that
Xaccepts data from the user and passes it to the daemon thru a FIFO.
X
X[ really two fifo.s used ]
X
XIn standard sysV unix, the at(1) facility is co-implemented as part of
Xcron(1M) and both facilities are available to trusted users.  Files are
Xstored in subdirectories using cron's name, like: /usr/lib/cron/FIFO.
XIn the unix-pc, however, smgr(1M) takes the place of cron, and is
Ximplemented more like sysIII unix's cron.  Therefore, it would not make
Xsense to use cron's name on directories that are used only by at(1).
XSo the filenames that I'll use will sort of parallel sysV, but use at's
Xname, like: /usr/lib/at/FIFO.
X
X[ no- used std sysV names ]
X
XSome of the design objectives are:
X
X	performance - don't use too much processor time or tie-up too
X		many of the system's resources.  In a small system like
X		the unix-pc, this is a major consideration.
X
X	security - always a consideration.  The ability to abuse at(1)
X		is well known.  There are basically three ways to break
X		security using at(1).  I won't detail them here, but I
X		will try to guard against all three in my design.
X
X	ease of use - at(1) should be easy for users to use, and easy
X		for the system admin to take care of.  I would very much
X		like to make the user's command line the same as sysV's
X		at(1), but I don't have a manual page from any version
X		of unix to follow.  Therefore, my choice of options and
X		command line arguments may not be *standard*.  I will
X		try to make reasonable choices for them, though.
X
X		[ options and args upwardly compatable with sysV ]
X		[ thanks to John Milton for his suggestions      ]
X
X	multi-user - I'll try to keep in mind that more than one user may
X		be using at(1) at the same time.
X
X	signals - handle them gracefully.  If the user presses the SIGINT
X		key, for example, there shouldn't be half-baked/temporary
X		files laying around.
X
XSo here's the basic design:
X
X	The daemon is started up at boot time or whatever, runs in the
X		background and has super-user uid.  It basically reads the
X		FIFO to see if anyone has sent it a message.  If no message
X		is received, it goes to sleep for a little while.  When it
X		wakes up, it checks the time and looks to see if any jobs
X		are scheduled to be done at that time.  If there is nothing
X		to do it just checks the FIFO and goes back to sleep.
X
X	The user calls the at(1) command and gives it the name of a file
X		containing the command he wants done or types the commands
X		in using stdin.  The user also supplies the time at which
X		he wants this stuff done.  At(1) checks to see if this user
X		is allowed to use the facility.  Opens up a temporary file.
X		Puts some environment setup stuff in the temp file (like
X		cd `pwd`) and copies the user's stuff into it.  It then sends
X		a message to the daemon thru the FIFO telling the name of the
X		temp file amoung other things.
X		
X		[ no- only stdin for cmds ]
X		[ no temp file used, writes file in spool directory ]
X
X	When the daemon gets the message from the FIFO, it moves the temp
X		file into the spool directory an gives it a unique name.  The
X		filename, time, uid and other info about the job is put on an
X		in-memory list of jobs; sort of like a symbol table.  This
X		list will probably be orderred on the time that the jobs are
X		supposed to be done so that the daemon can determine which
X		job to run when as quickly as possible.  Otherwise the daemon
X		would have to scan the whole list everytime it wakes up.
X
X		[ job file is already in the spool directory ]
X
X	At some point the daemon will wake up, check its list and find that
X		it is time to run the job.  It will fork off a process, set
X		the uid and gid to the job's owner and call the shell to run
X		it.  I may incorporate the ability to use either sh(1) or
X		ksh(1) and the ability to set a nice value for the job.  The
X		job will be taken off the daemon's list and the file removed.
X
X		[ uses whatever shell defined in /etc/passwd for the user ]
X		[ user can specify nice value ]
X
X	Some details that must be answered: How to connect stdin, stdout and
X		stderr for a job?  If ksh(1) is used, what to do with history?
X		How is the job file removed; by the daemon or by the shell?
X		Can the user delete a job before it runs; if so how does he
X		find it?
X
X		[ stdin is job file, stdout and stderr mailled to user ]
X		[ ksh histfile same as user's. used when read -s or print -s ]
X		[ job rmv'd by unlinking file and/or send rmv msg to daemon ]
X		[ at -l lists jobs, at -r removes them ]
X
X	There is also the consideration of incorporating a batch(1) facility
X		into at(1).  It would be relitively easy to do a simple batch
X		that doesn't monitor system load, just set the maximum nice
X		value and let-her-go.  You could get real fancy, by building
X		a histogram of system load factors and intelegently picking
X		a historically low-load time to run batch jobs; but I think
X		that is going too far.  One simple possiblity is to just count
X		the number of active processes, and if the number is close to
X		the minimum number known to batch, and has stayed close to the
X		minimum for awhile; then run a batch job.  How do you count
X		the number of processes?  Well you could do ps(1) and count
X		the number of lines, but this would create alot of overhead.
X		The other way is to count the kernal's process table directly.
X		I know how to do this.  It's not a easy as it sounds, though.
X		Hmmmm, we'll see, let's concentrate on at(1) first.
X
X		[ batch just runs the job at maximum nice ]
X
X/* --------------------------------------------------------------
X   FIFOs:  daemon ----JNUM----> user
X	   daemon <---FNAM----- user
X
X   Daemon generates unique jobnumbers and sticks them in JNUM fifo.
X   User gets jobnumber from JNUM fifo, uses it as a filename, and
X   puts its information in that file.  When user finishes building
X   the file, it writes the filename(=jobnumber) into FNAM fifo.
X   Daemon reads filename from FNAM fifo, opens the file, reads some
X   info from it and builds its in-memory list.  When the time comes,
X   the daemon runs the job and writes the jobnumber back on the JNUM
X   fifo.  The reasons to do it this way are:  (1) daemon's in-memory
X   list can't overflow because it limits the number of jobnumbers
X   available to the user.  (2) daemon can always build its in-memory
X   list from files in the spool directory at startup time.  (3) the
X   user can build its files directly in the spool directory.  (4) if
X   the daemon finds a file in the spool directory which is not on
X   its list, it means the user has crashed; it can remove the file
X   and make that jobnumber available again.  (5) if the user cancels
X   the job before writing its filename into the FNAM fifo, he writes
X   it back on the JNUM fifo (sneeky!).  (6) the last line in every
X   job file is specially marked.  If everything crashes this line
X   will be missing.  The daemon removes files that don't have this
X   special line at startup.  (7) the daemon opens the job file and
X   unlinks it when the job is run.  The jobnumber is immediately
X   available and the file is deleted automatically when the shell is
X   done, even if something or everything crashes.
X   -------------------------------------------------------------- */
X
X   [ #4 not implemented ]
X   [ caveate: the fifos must be big enough to hold all the job no.s ]
X   [[ #6 jobs are marked with a magic number not special last line ]]
X
Xcron facility  4/89 D.Lashomb
X
XThis project is to add the cron capabilities to the at(1) facility
Xalready implemented.  Some of the key ideas are:
X(1) users are screened thru cron.allow and cron.deny
X(2) only one crontab file for each user
X(3) format of crontab files:
X	# any line beginning with a # is a comment
X	mm hh DD MM ww <action>
X		schedule fields are integers incl ran-ges com,mas
X		action upto \n or first % remainder: %=\n stdin to command
X(4) the daemon scans all crontabs at startup and when new ones are added
X(5) when daemon scans a crontab it generates a job (or jobs) for the next
X    scheduled action.
X(6) when the daemon runs a cronjob it rescans the asscociated crontab, again
X    generating jobs for the next scheduled actions for that user.
X
X[ crontab(1) not implemented yet.  I did cronjob(1) instead. ]
X[ most of the hooks for crontab are in the daemon.  I'll add ]
X[ crontab sometime soon [[ crontab implemented ]]            ]
X[[ #4,5,6 scanning the crontab is a function of the crontab(1) ]]
X[[ command, the daemon has nothing to do with crontab files    ]]
X
X==================
X
XUser's crontabs are stored in /usr/spool/cron/crontabs with the filename = uid.
XThis is different from sysV, where filenames=lognames.  It also means that you
Xcan't have multiple crontabs for multiple login names with the same uid.  There
Xare some problems in this area with at(1) too.  It could be fixed with great
Xeffort.
X
X[ This is mostly right! My programs go by uid not logname ]
X
XAnother thing is that the crontab(1) command must have read access to the
Xuser's files and yet has to be suid cron to write into the spool dir.  There
Xare a couple of solutions to this.  Could have crontab(1) only a little
Xscript that opens the user's file and pipes it into stdin of the *real* cmd.
XAnother solution would be to have a group called "cron" instead of a login.
X
XHere's how to do it: at(1), batch(1), and crontab(1) are all the same program
Xwhich runs as effective uid = cron, real uid = the user.  Crontab(1) can
Xwrite into the spool directories, but can't read the user's file because its
Xeffective uid is cron.  So it spawns a child that does setuid back to the
Xreal user's uid and pipes the user's file in.
XUser calls crontab(1) and gives the name of his file (or stdin).
XCrontab(1) spawns a "cat" process to pipe the user's file in.  For every line
Xin every user's crontab files, a ct_job is created.  The only reason to keep
Xa copy of the user's crontab file in ...spool/crontabs is so the user can get
Xa copy back with the -l option.  The daemon doesn't use it at all.
X
X[ hooks in the daemon for CR_TAB ]
X[ crontab opens user's file after setuid() back to real uid ]
X[[ at(1), batch(1), cronjob(1) and crtabj(1) are all the same program. ]]
X[[ crontab(1) parses the crontab file and generates multiple calls to  ]]
X[[ crtabj(1) to create the jobs - one for each line in the crontab file]]
X[[ note: bug in setuid() won't let you setuid(getuid()) for real uid=0 ]]
X[[       so crontab command must run as SUID root, intead of SUID cron ]]
X
X=================
X
XAnother problem concerns the environment for cron_jobs.  Unfortunately the
XsysV manual page specifically states that a default environment is setup for
Xcron_jobs; incl $HOME (ok), $LOGNAME (ok), $SHELL (so-so) and $PATH (ng).
XWhereas at(1) could just grab the current environment for its jobs, cron will
Xhave to figure-out what to give its jobs.  The sysV manual also specifically
Xstates the .profile will not be executed.  The biggest problem is $PATH.
X$HOME, $LOGNAME and $SHELL can be setup from the passwd file.  If the user's
Xlogin shell is ksh, then $ENV could be executed, if setup.  Now there are
Xreal problems in this area!  In my opinion, a cron_job should be equivelent
Xto at(1), except that it is cyclic instead of one-shot.  Barring that; cron
Xshould be equivelent to logging in and executing the commands by hand, so
Xthat your environment is recreated.  It is MUCH cheaper, however, to do it
Xthe sysV way - for one thing you don't have to save the user's environment
Xanywhere.  But there are a great many programs that depend on various environ
Xvariables being setup.  The best way I think is this:  the crontab(1) command
Xdoes a cd to $HOME first and then saves the environment like at(1). [maybe]
X
X[ uses full user environment as exists when the job is created ]
X[[ doesn't cd to $HOME either, uses current working directory when created ]]
X
X==================
X
XMarch 15, 1990  -- a few things that should be fixed
X
XI released version 3.0.1 to usenet on Dec 21, 89.  Since then I have received
Xmostly positive feedback about this facility.  Only one person reported any
Xtrouble and that was traced to the use of the stty(1) command in his ksh $ENV
Xfile.  I myself, however, have discovered a few little problems.  I have cron
Xrunning on three machines.  Machine #1, crlake, runs 24 hours a day and has
Xhad no trouble.  Machine #2, crlak2, is a machine which is shutdown every
Xnight (my wife doesn't like the noise).  And, machine #3, peanut, has a bad
Xbattery or RTC chip or something - it doesn't keep proper time when shutdown.
XFrom my experience with these machines, and other considerations, here are a
Xfew things that should be changed:
X
X	The CATCHUP scheme is only effective on at(1) jobs.  It does not
X	work for crontab(1) or cronjob(1) jobs.  This is because the date
X	stored in the job file for crontab(1) and cronjob(1) jobs doesn't
X	control execution, rather the resched() function takes care of
X	scheduling execution times.  What happens on a machine that is
X	shutdown every night is that crontab(1) and cronjob(1) jobs which
X	should be executed at night never get done.  The hard part of
X	making CATCHUP work for these jobs is determining when the machine
X	went down and deciding whether to run the job or not.  I could
X	update the date in the job file each time the job is executed, but
X	that wouldn't be very efficient.  Cron's log file, however, is
X	used to record every action.  So what I can do is check the mod
X	time of the log file to determine (about) when the machine went
X	down.  Ok, let's say the machine went down 8 hrs ago and you are
X	now bringing it back up.  Cron missed some jobs, and is now
X	catching them up.  What about jobs that were, say, supposed to
X	execute hourly - does cron execute them 8 times or just once?  I
X	say do them just once.  Most likely these jobs are cleanup-type
X	jobs or uucp polling jobs anyway.
X
X[ added -x option to at(1)... to execute jobs at will.  When bringing ]
X[ the system up after a shutdown, the system admin can "-x" any jobs  ]
X[ he/she thinks should have been run but weren't.                     ]
X
X	The sleep time in the daemon's sleep-wake cycle gets screwed-up
X	if someone changes the system time (ie with date command).  What
X	happens is that the daemon goes into either a 1-sec cycle or it
X	sleeps for a long time until it resync-s with the system time
X	(depending on whether the system time is set backwards or ahead).
X	The fall back to 1-sec sleep was intended to take care of the
X	situation in which the daemon's processing time while awake might
X	be longer than the GRAINULARITY time.  If this was caused by a
X	temporary heavy load, then the 1-sec sleep would allow the daemon
X	to keep chugging along until the load cooled off.  In all honesty,
X	I never anticipated that someone would change the system clock.
X	BTW- If you've got a machine with a dead battery, you should edit
X	the /etc/rc script to let the operator set the clock before doing
X	anything else.  OK, so what if someone changes the system time?
X	Well, first I've got to detect that the clock has been changed.
X	This isn't too hard, if the calculated sleep time is more than
X	GRAINULARITY or a lot less than zero, then the clock was changed.
X	Next, I've got to figure out what to do about it.  Probably
X	something like catchup should happen.  If the system clock is set
X	back, the jobs should be rescheduled and so some jobs might be
X	run twice.  If the system clock is set ahead, the jobs should be
X	caught up so that the jobs get run at least once.
X
X[ The 1-sec sleep stuff was retained for minor overloads.  If system ]
X[ clock is set significantly ahead or back, the daemon's idea of the ]
X[ time is reset to the system clock.  Jobs might still be run twice  ]
X[ or skipped over.  Ain't perfect, but it's better than it was.      ]
X
X	I'm not realy comfortable with the way that most jobs are marked
X	with "# job done".  The idea for this was to protect against
X	half-baked jobs in case the user crashed while creating a job.
X	But crontab(1) jobs are not marked, and so don't get the same
X	protection.  A better idea would be to have a checksum as part of
X	the job header.  This will involve seeking back to the beginning
X	of the job file so that the checksum can be written, which causes
X	some loss of performance.  Also, listing the "user" portion of
X	a job with the "-lu" option, causes the newline preceding the
X	"# job done" mark to be output.  This newline was not enterred
X	by the user, and so it should not be output.  Changing to a
X	checksum scheme will eliminate this minor bug too.
X
X[ "# job done" eliminated.  Jobs are now marked with a magic number ]
X
X	Currently there is no use of register variables in the code.  By
X	sprinkling the code with register declarations, I could probably
X	increase the efficiency some.  Although, IMHO, the code is quite
X	good as is.
X
X[ sprinkled code with register variables ]
X
X	The code could be better organized on a source level.  The reading
X	and writing of the environment portion of a job file is currently
X	spread out in whatever source code that needs it.  It should be
X	consolodated into one source file.
X
X[ I tried to clean up the source ]
X
X	Fix execlp in crontab.c (no 0 ending arg list).
X
X[  fixed ]
X
X	Rdfifo and wrfifo might as well use jjj directly instead of
X	passing &jjj to these routines.
X
X[ yup ]
X
X	Add "all" to -l option for symmetry with -r option
X
X[ yup ]
X
X	A better alternative to CATCHUP for cron{tab|job} jobs might be to
X	just have a -x option which causes said job(s) to run immediately.
X	The sysadmin could simply '-x all' the jobs that were scheduled to
X	run on a night when the system was down, could even be put in /etc/rc.
X
X[ "-x" option added, CATCHUP still used too ]
X
XAug 8, 1990  The above work on the cron programs has been delayed for most
Xof the summer.  The reason is that there is a nasty little bug in the at.c
Xprogram that causes the captured current working directory to be wrong.  I
Xjust couldn't get a handle on it.  The c.w.d. is correct 99% of the time,
Xit's that 1% that had me baffled.  Finally, someone on Usenet had a simalar
Xproblem.  The problem is that the /bin/pwd command does not necessarily
Xoutput the c.w.d. in one shot.  The reader on the end of the pipe must keep
Xreading until it sees a '\n' to be sure that it got it all.  I am grateful
Xto all "net-people" that helped whoever it was that had the problem, and
Xunknowingly help me with my problem too.
X
X[ fixed my getwd() function to keep reading until it got the whole line ]
SHAR_EOF
$TOUCH -am 1016164590 Design_Notes &&
chmod 0644 Design_Notes ||
echo "restore of Design_Notes failed"
set `wc -c Design_Notes`;Wc_c=$1
if test "$Wc_c" != "19046"; then
	echo original size 19046, current size $Wc_c
fi
fi
# ============= Examples ==============
if test X"$1" != X"-c" -a -f 'Examples'; then
	echo "File already exists: skipping 'Examples'"
else
echo "x - extracting Examples (Text)"
sed 's/^X//' << 'SHAR_EOF' > Examples &&
XThe following are examples of cronjobs and crontabs that may assist
Xyou in setting up my cron facility on your machine.  The time
Xschedules and the names of the various scripts shown are typical of
Xa Unix-PC machine.  Of course, the exact time schedules and the names
Xof the various scripts shown here would be tailored to your specific
Xsystem.
X
X***************
X
XThe UUCP system has a number administrative tasks that are usually
Xexecuted by cron at various times.  These tasks are usually performed
Xby running the /usr/lib/uucp/uudemon.{hr|day|wk} scripts at the
Xappropriate times.
X
XIn order to setup these tasks in the cron facility, it is necessary
Xto login as the UUCP administrator.  This is accomplished on the
XUnix-PC by logging in as "root" and doing an "su - uucpadm".
X
XThe hourly uudemon script is a good canidate for execution as a
Xcronjob rather than crontab.  CR_JOBs run a little more efficiently
Xthan CR_TAB jobs.  This makes it a little less bothersome to your
Xusers when it kicks in every hour and sucks away cpu cycles.
X
XEdit the uudemon.hr script to attach " >/dev/null 2>&1" to the
Xcommands in the script which might produce an output that you don't
Xcare about.  If you don't, any output will be mailed to "uucpadm",
Xproducing a lot of junk mail.  Then type in the following command:
X
X	cronjob -n19 '40 * * * *' < /usr/lib/uucp/uudemon.hr
X
XThis will make the CR_JOB a copy of the hourly script and set it up
Xto run at 40 minutes after every hour and will run it with a heavy
Xnice value.  Note that the CR_JOB is only a copy of the script.  If
Xyou edit the uudemon.hr script at a later time, you will have to
Xremove the original CR_JOB (cronjob -r _jobnumber_) and make a new
XCR_JOB by typing in the above command again.
X
XThe daily and weekly uudemon scripts are setup via crontab.  These
Xscripts usually run late at night, so the efficiency considerations
Xaren't as important.  Type in the following command:
X
X	crontab <<'EOF'
X	# ---------- crontab for uucp ----------
X
X	#-n19
X	# uudemon.hr executed by cronjob for better efficiency
X	# 40  *  *  *  *	/usr/lib/uucp/uudemon.hr >/dev/null
X	00  4  *  *  *		/usr/lib/uucp/uudemon.day >/dev/null
X	30  5  *  *  Sun	/usr/lib/uucp/uudemon.wk >/dev/null
X	EOF
X
XThe cron facility will save this crontab for you and create two CR_TAB
Xjobs to run the uudemon.day and uudemon.wk scripts.  Note that it is
Xthe uudemon.{day|wk} scripts themselves that are run at the scheduled
Xtimes.  If you edit these scripts there is no need to change the crontab.
X
X***************
X
XGeneral system maintainence is usually performed on a regular basis
Xby the superuser.  Login as "root" and enter the following command:
X
X	crontab <<'EOF'
X	# ---------- crontab for root ----------
X
X	#-N20
X	15  3  *  *  Sun	/etc/clockupd.wk >/dev/null
X	#-n0
X	15  5  *  *  Mon	/etc/cleanup.wk >/dev/null
X	EOF
X
XThe cron facility will save this crontab for you and create two CR_TAB
Xjobs to run the clockupd.wk and cleanup.wk scripts.  Note the use of
Xthe nice switches to run the clockupd.wk script at high priority and
Xthe cleanup.wk script at normal priority.
X
X***************
X
XThe cron facility itself keeps a log of all its activities.  This log
Xshould be cleaned up periodicly so it doesn't grow too big.  Login as
X"root" and do a "su - cron", then type in the following:
X
X	cronjob '0 0 * * Sun' <<'EOF'
X	cp /usr/lib/cron/log /usr/lib/cron/log-old
X	rm -f /usr/lib/cron/log-old.z
X	pack /usr/lib/cron/log-old >/dev/null 2>&1
X	cronjob -c
X	EOF
X
XThis will create a CR_JOB which, at midnight every Sunday, saves and
Xsqueezes last week's log and starts a fresh log for the coming week.
X
X***************
X
XThe Unix-PC has a program called "smgr" which uses the file
X/usr/lib/crontab to provide (limitted) cron facilities (no user
Xcrontabs, no at(1) program, ...).  This older form of cron, which
Xuses the file /usr/lib/crontab, is, I believe, like the system-III
Xcron.  Other machines may also have a similar vendor-supplied cron.
XThere is no reason why you can't run both the old cron and my cron
Xtoo.  On the Unix-PC, if you would like to continue to run the smgr
Xprogram in order to partake of its other functions (eg. date display
Xat the top of the screen), but would like to let my program handle
Xall the cron duties; just comment (#) all the lines in the
X/usr/lib/crontab file and create equivelent crontabs (cronjobs) with
Xmy facility.
SHAR_EOF
$TOUCH -am 1022100690 Examples &&
chmod 0644 Examples ||
echo "restore of Examples failed"
set `wc -c Examples`;Wc_c=$1
if test "$Wc_c" != "4358"; then
	echo original size 4358, current size $Wc_c
fi
fi
# ============= Files ==============
if test X"$1" != X"-c" -a -f 'Files'; then
	echo "File already exists: skipping 'Files'"
else
echo "x - extracting Files (Text)"
sed 's/^X//' << 'SHAR_EOF' > Files &&
XSize
XDesign_Notes
XExamples
XFiles
XInstall
XName
XREADME
XRemove
Xat.1
Xat.c
Xconvertjob.c
Xcron.1
Xcron.h
Xcrontab.1
Xcrontab.c
Xdaemon.c
Xdir.c
Xfifo.c
Xgetwd.c
Xjob.c
Xjob.h
Xlog.c
Xlogin.c
Xmakefile
Xmemlist.c
Xmkfifo.c
Xparsesched.c
Xparsetime.c
Xresched.c
Xversion
SHAR_EOF
$TOUCH -am 1022100790 Files &&
chmod 0644 Files ||
echo "restore of Files failed"
set `wc -c Files`;Wc_c=$1
if test "$Wc_c" != "244"; then
	echo original size 244, current size $Wc_c
fi
fi
# ============= Install ==============
if test X"$1" != X"-c" -a -f 'Install'; then
	echo "File already exists: skipping 'Install'"
else
echo "x - extracting Install (Text)"
sed 's/^X//' << 'SHAR_EOF' > Install &&
X#   Install for the cron(1M) facility  4/89,10/90 D.Lashomb
X
XLOCAL=/usr/local
XBIN=/usr/local/bin
XLIB=/usr/lib/cron
XSPOOL=/usr/spool/cron
XDAEMONS=/etc/daemons
XSRC=$HOME/Filecabinet/SRC
XmySRC=$SRC/Cron
XDOCS=$HOME/Filecabinet/DOCS
XmyDOCS=$DOCS/Cron
X
Xif grep '^cron:' /etc/passwd
Xthen
X
X########################################
X# upgrading old version to new version
X########################################
X
X	cat <<END
X
XInstall for cron(1M) facility:
X
XYou already have a login named "cron" in
Xyour passwd file.  I assume that this is
Xa re-install of my cron facility for the
Xpurpose of upgrading to the new version.
X
XEND
X	echo "shall I continue y/[n]? \c"
X	case "`line`" in
X	[Yy]*)	:
X		;;
X	*)	exit 2
X		;;
X	esac
X
X	echo "killing the cron daemon"
X	I=`ps -e | grep 'cron' | cut -c1-6`
X	for i in $I
X	do
X		kill -9 $i
X	done
X
X	echo "compiling the programs"
X	make all
X	make clean
X
X	echo "copying new programs over the old ones"
X	cp cron $DAEMONS/cron
X	cp at $BIN/at
X	cp crontab $BIN/crontab
X	rm cron at batch cronjob crtabj crontab
X
X	# convert old jobs to new style
X	ls $SPOOL/atjobs/* >/dev/null 2>&1 && {
X		cat <<END
X
XYou have old jobs in the spool directory.
XThe new cron daemon is not compatable with
Xold style jobs.
X
XEND
X		echo "convert old jobs to new style [y]/n? \c"
X		case "`line`" in
X		[Nn]*)	:
X			;;
X		*)	for i in `ls $SPOOL/atjobs`
X			do
X				./convertjob $SPOOL/atjobs/$i >temp
X				cp temp $SPOOL/atjobs/$i
X			done
X			rm temp convertjob
X			;;
X		esac
X		}
X
X	cat <<END
X
XYou may (or may not) have the source code and
Xdocumentation for the old version saved in
X$mySRC and $myDOCS
XI'll remove the old stuff and put the new
Xsource code and docs there if you want.
X
XEND
X	echo "remove old and save new [y]/n? \c"
X	case "`line`" in
X	[Nn]*)	:
X		;;
X	*)	rm -f $mySRC/*
X		rm -f $myDOCS/*
X		for i in $SRC $mySRC $DOCS $myDOCS
X		do
X			[ -d $i ] || {
X				mkdir $i
X				chown $LOGNAME $i
X				chgrp users $i
X				chmod 0755 $i
X				}
X		done
X
X		echo "putting source code in $mySRC"
X		ln *.h *.c makefile version $mySRC
X		echo "putting manual pages in $myDOCS"
X		ln *.1 README Design_Notes Examples $myDOCS
X		chown $LOGNAME *.h *.c makefile version *.1 README Design_Notes Examples
X		chgrp users *.h *.c makefile version *.1 README Design_Notes Examples
X		chmod 0644 *.h *.c makefile version *.1 README Design_Notes Examples
X		;;
X	esac
X
Xelse
X
X########################################
X# installing cron for the first time
X########################################
X
X	cat <<END
XInstall for cron(1M) facility:
X
XI will add a login named "cron" to your
Xpasswd file!  If you don't want me messing
Xwith your password file, stop me now.
X
XEND
X	echo "shall I continue y/[n]? \c"
X	case "`line`" in
X	[Yy]*)	:
X		;;
X	*)	exit 2
X		;;
X	esac
X
X	# find an unused uid
X	for uid in 50 51 52 53 54 55 56 57 58 59 60 bad
X	do
X		cut -d: -f3 /etc/passwd | grep $uid >/dev/null || break
X	done
X	[ "$uid" = "bad" ] && {
X		echo "can't find unused uid"
X		exit 1
X		}
X
X	# find gid for "other"
X	gid=`grep "other" /etc/group | cut -d: -f3`
X	[ "$gid" = "" ] && {
X		echo "can't find group 'other'"
X		exit 1
X		}
X
X	echo "cron:NONE:$uid:$gid:cron facility:/usr/lib/cron:" >>/etc/passwd
X
X	echo "compiling the programs"
X	make all
X	make clean
X
X	echo "making directories"
X	[ -d $LOCAL ] || {
X		mkdir $LOCAL
X		chown root $LOCAL
X		chgrp users $LOCAL
X		chmod 0755 $LOCAL
X		}
X	[ -d $BIN ] || {
X		mkdir $BIN
X		chown bin $BIN
X		chgrp bin $BIN
X		chmod 0755 $BIN
X		}
X	[ -d $LIB ] || {
X		mkdir $LIB
X		chown cron $LIB
X		chgrp bin $LIB
X		chmod 0700 $LIB
X		}
X	[ -d $SPOOL ] || {
X		mkdir $SPOOL
X		chown cron $SPOOL
X		chgrp bin $SPOOL
X		chmod 0700 $SPOOL
X		}
X	[ -d $SPOOL/atjobs ] || {
X		mkdir $SPOOL/atjobs
X		chown cron $SPOOL/atjobs
X		chgrp bin $SPOOL/atjobs
X		chmod 0700 $SPOOL/atjobs
X		}
X	[ -d $SPOOL/crontabs ] || {
X		mkdir $SPOOL/crontabs
X		chown cron $SPOOL/crontabs
X		chgrp bin $SPOOL/crontabs
X		chmod 0700 $SPOOL/crontabs
X		}
X	[ -d $DAEMONS ] || {
X		mkdir $DAEMONS
X		chown root $DAEMONS
X		chgrp sys $DAEMONS
X		chmod 0750 $DAEMONS
X		}
X	for i in $SRC $mySRC $DOCS $myDOCS
X	do
X		[ -d $i ] || {
X			mkdir $i
X			chown $LOGNAME $i
X			chgrp users $i
X			chmod 0755 $i
X			}
X	done
X
X	echo "moving the programs to their proper places"
X	mv cron $DAEMONS/cron
X	chown root $DAEMONS/cron
X	chgrp bin $DAEMONS/cron
X	chmod 0700 $DAEMONS/cron
X
X	mv at $BIN/at
X	mv batch $BIN/batch		# a link to at
X	mv cronjob $BIN/cronjob		# a link to at
X	mv crtabj $BIN/crtabj		# a link to at
X	chown cron $BIN/at
X	chgrp bin $BIN/at
X	chmod 4711 $BIN/at
X
X	mv crontab $BIN/crontab
X	chown root $BIN/crontab
X	chgrp bin $BIN/crontab
X	chmod 4711 $BIN/crontab
X
X	echo "Ok, let's setup the allow and deny files."
X	rm -f $LIB/at.allow
X	rm -f $LIB/at.deny
X	rm -f $LIB/cron.allow
X	rm -f $LIB/cron.deny
X
X	cat <<END
X
XYou can choose to let at(1) and batch(1) be used by
Xall, some or none of the users in the following ways:
X
X  1 - allow everybody to use at(1) and batch(1)
X  2 - allow only the users you name
X  3 - allow everybody EXCEPT the users you name
X  4 - let only the superuser use it
X
XEND
X	echo "pick a number-> \c"
X	case "`line`" in
X	"1")
X		> $LIB/at.deny
X		chown cron $LIB/at.deny
X		chgrp other $LIB/at.deny
X		chmod 0600 $LIB/at.deny
X		;;
X	"2")
X		echo "enter blank name to end list"
X		while :
X		do
X			echo "enter allowed user's name-> \c"
X			read name
X			[ "$name" ] || break
X			echo $name >>$LIB/at.allow
X		done
X		chown cron $LIB/at.allow
X		chgrp other $LIB/at.allow
X		chmod 0600 $LIB/at.allow
X		;;
X	"3")
X		echo "enter blank name to end list"
X		while :
X		do
X			echo "enter denied user's name-> \c"
X			read name
X			[ "$name" ] || break
X			echo $name >>$LIB/at.deny
X		done
X		chown cron $LIB/at.deny
X		chgrp other $LIB/at.deny
X		chmod 0600 $LIB/at.deny
X		;;
X	*)
X		echo "ok, only the superuser can use it"
X		;;
X	esac
X
X	cat <<END
X
XYou can choose to let cronjob(1), crtabj(1) and
Xcrontab(1) be used by all, some or none of the users
Xin the following ways:
X
X  1 - allow everybody to use them
X  2 - allow only the users you name
X  3 - allow everybody EXCEPT the users you name
X  4 - let only the superuser use it
X
XEND
X	echo "pick a number-> \c"
X	case "`line`" in
X	"1")
X		> $LIB/cron.deny
X		chown cron $LIB/cron.deny
X		chgrp other $LIB/cron.deny
X		chmod 0600 $LIB/cron.deny
X		;;
X	"2")
X		echo "enter blank name to end list"
X		while :
X		do
X			echo "enter allowed user's name-> \c"
X			read name
X			[ "$name" ] || break
X			echo $name >>$LIB/cron.allow
X		done
X		chown cron $LIB/cron.allow
X		chgrp other $LIB/cron.allow
X		chmod 0600 $LIB/cron.allow
X		;;
X	"3")
X		echo "enter blank name to end list"
X		while :
X		do
X			echo "enter denied user's name-> \c"
X			read name
X			[ "$name" ] || break
X			echo $name >>$LIB/cron.deny
X		done
X		chown cron $LIB/cron.deny
X		chgrp other $LIB/cron.deny
X		chmod 0600 $LIB/cron.deny
X		;;
X	*)
X		echo "ok, only the superuser can use it"
X		;;
X	esac
X
X	echo "putting source code in $mySRC"
X	ln *.h *.c makefile version $mySRC
X	echo "putting manual pages in $myDOCS"
X	ln *.1 README Design_Notes Examples $myDOCS
X	chown $LOGNAME *.h *.c makefile version *.1 README Design_Notes Examples
X	chgrp users *.h *.c makefile version *.1 README Design_Notes Examples
X	chmod 0644 *.h *.c makefile version *.1 README Design_Notes Examples
X
Xfi
X
Xcat <<END
X
XThe installation of the cron(1M) facility is now
Xcomplete.  However you will have to reboot the
Xsystem in order to fire-up the daemon.
XEND
Xsleep 5
Xexit 0
SHAR_EOF
$TOUCH -am 1022115090 Install &&
chmod 0744 Install ||
echo "restore of Install failed"
set `wc -c Install`;Wc_c=$1
if test "$Wc_c" != "7286"; then
	echo original size 7286, current size $Wc_c
fi
fi
# ============= Name ==============
if test X"$1" != X"-c" -a -f 'Name'; then
	echo "File already exists: skipping 'Name'"
else
echo "x - extracting Name (Text)"
sed 's/^X//' << 'SHAR_EOF' > Name &&
XImproved cron(1M) facility by D.Lashomb
SHAR_EOF
$TOUCH -am 0728232689 Name &&
chmod 0644 Name ||
echo "restore of Name failed"
set `wc -c Name`;Wc_c=$1
if test "$Wc_c" != "40"; then
	echo original size 40, current size $Wc_c
fi
fi
# ============= README ==============
if test X"$1" != X"-c" -a -f 'README'; then
	echo "File already exists: skipping 'README'"
else
echo "x - extracting README (Text)"
sed 's/^X//' << 'SHAR_EOF' > README &&
X
X/* ------------------------- NOTICE -----------------------------
X
X   at(1) batch(1) cronjob(1) crtabj(1) crontab(1) cron(1M)
X	(c) copyright April 10, 1989 by Donald Lashomb
X	(c) copyright October 16, 1990 by Donald Lashomb
X
X   This program is free.  Use it, modify it, copy it, give a copy
X   to a friend; I simply request the following provisions be observed:
X
X   1. My name as original author and this notice remain intact.
X   2. This program (or any modification of it) is not to be sold
X      for profit.
X   3. If this program is included in commercial products, there be
X      no charge for it.
X   4. This program must be distributed with source code.  Compiled-
X      only or binary-only distribution of this program is not allowed.
X      The administrator of any system that uses this program must have
X      full access to the source code.
X   5. If you enhance this program, discover a bug, have any comments
X      about it (or flames) please let me know.
X   
X   		Donald Lashomb
X   		Main Street
X   		Cranberry Lake, NY 12927
X
X   -------------------------------------------------------------- */
X
X
XCron(1M) is a facility that allows you to schedule commands that will be
Xexecuted at a later time.  At(1), batch(1) and crontab(1) are available
Xon many unix systems, but not the AT&T UNIX-pc; so I wrote my own.
XBatch(1) is just a special form of at(1) which executes commands "now"
Xat low priority.  Crontab(1) lets users have their own crontab files.  A
Xnew cronjob(1) command is included which allows you to repeatedly execute
Xjobs according to a schedule.  Also included is a new crtabj(1) command
Xwhich actually underlies the crontab(1) command, but has some usefulness
Xto the user.
X
XI made some improvements over the standard sysV facility (as I understand
Xit).  The manual pages explain this stuff better than I can do here, but
Xhere are some highlights:
X
X	*  the ability to specify a nice value, even neg for root
X
X	*  great variety of listing options
X
X	*  accepts names like Sun Mon etc in times, dates, schedules
X
X	*  security strictly enforced by real uid
X
X	*  new cronjob command runs like at(1), but repetitively like
X	   crontab.  I use this instead of crontab, it's more efficient.
X
X	*  crtabj command is what really does crontab
X
X	*  everything (almost) compatable with standard sysV versions
X
X                          ***************
X
XThe facility is implemented in two parts: the user commands and the
Xdaemon.  These programs communicate through FIFOs.  Heres how it works:
X
XThe daemon is started at boot-time and runs in the background.  The 1st
X	thing it does is check the spool dir to see if there are any
X	jobs already there, and builds its in-mem job list.  The jobnumber
X	is the same as the filename for all jobs.  The daemon then writes
X	any free jobnumbers into the JNUMBS fifo, and enters its main loop
X	of sleeping for awhile, waking up and checking the FNAMES fifo.
X
XThe user calls the at(1) command, specifying the time when the job should
X	be run on the command line.  At(1) obtains a jobnumber from the
X	JNUMBS fifo and creates a file of that name in the spool dir.  It
X	writes some special information, eg. user's current environment,
X	into the job file and starts to read its stdin.  Everything that
X	the user types upto a cntl-D will be written into the job file.
X	When the user finishes, at(1) marks the end of the job, closes
X	the file and writes its name (=jobnumber) into the FNAMES fifo.
X
XThe next time the daemon wakes up, it will find the filename in the FNAMES
X	fifo and add it to its in-mem job list.  It then checks that list
X	to see if any jobs are scheduled to run at that time.  If it is
X	time to run a job, the daemon forks off a process that reads the
X	job file and recreates the environment that existed at the time
X	the job was written by the user, and runs the job.  The daemon 
X	removes the job file and makes the jobnumber available again by
X	writting it into the JNUMBS fifo.
X
XI tried to make things upwardly compatable with the sysV version, at least
Xfrom the user's point of view.  The implementation is obviously different:
X
XsysV:				| my version:
X--------------------------------|-----------------------------------------
Xone FIFO and signals for commu- | two FIFOs  JNUMBS daemon-->user
Xnication between daemon & user  |            FNAMES user-->daemon
X				|
Xatjobs filenames are an encoded | atjobs filenames are the same as the
Xform of execution time          | jobnumber.  other jobs here too.
X				|
Xcrontabs filenames are users'   | crontabs filenames are users' uid
Xlogin name			| number
X				|
Xsecurity based on login name	| security based on uid and login name
X				|
Xmultiple crontabs per uid if	| only one crontab per uid
Xlogin names different?		|
X				|
Xfile /usr/lib/cron/queuedefs    | user can specify nice value each job
Xtells daemon nice value and how | MAXKIDS daemon parameter sets limit
Xmany jobs to run at one time	| on how many jobs to run at one time
X				|
Xcrontabs run with limited env	| crontabs restore full user environment
X				|
Xcrontabs implemented ????	| crontab creates a separate job for
X				| every line in every crontab file
X
X                          ***************
X
XLike sysV, if you want to change your crontab you have to do something
Xlike this:
X		crontab -l > temp	# get a copy of my current crontab
X		crontab -r		# remove it from cron's inventory
X		vi temp			# make the changes
X		crontab < temp		# re-submit it to cron
X
X                          ***************
X
XCRONJOB vs CRONTAB
X------------------
XCronjob is a new command that can do many of the same things that crontab
Xis used for.  Like crontab, its jobs run repetitively according to a user
Xsupplied schedule.  Where crontab limits you to a single command per time
Xschedule (I'm talking about a single line in a crontab file here), cronjob
Xallows you to do a whole bunch of commands per scheduled execution.  What
Xusually happens with crontab is that the command part of a crontab line
Xactually calls a shell script.  With cronjob the job *is* the shell script.
XI/O overhead is lower because it's one less file that has to be openned.
XCPU load is lower because one less process that needs to be spawned.  There
Xare disadvantages, of course.  For one thing, with crontab everything is
Xin one place, easy to find.  With cronjob you've got to search every job
Xto find the one you are looking for.  Another thing is that with crontab
Xyou can do one >/dev/null, with cronjob you've got to do this for every
Xcommand in the "script".
X
X                          ***************
X
XINSTALLING THE CRON(1M) FACILITY:
X
X	(1) add a user called "cron" to the system
X	(2) edit cron.h to change parameters (optional)
X	(3) compile the programs
X	(4) create the proper directories and files
X	(5) move the programs where they belong
X	(6) create and edit the allow and deny files
X	(7) reboot to get the daemon running
X
XNote: an Install script for the UNIX-PC is included with this package.
XI don't know what method you use for installing software on your system.
XDo you use the user agent?  If so, cpio all the files together, add an
X+IN suffix and click on it with the mouse.  From the shell, all you'd
Xhave to do is su to root and run the Install script.  Of course, you can
Xalways do the installation "by hand" if you want.
X
XWARNING - the Install script modifies your /etc/passwd file!
X	  this facility uses a login name 'cron' for its operations.
X
X
X(1) Edit your /etc/passwd file to add a user named "cron".  Login "cron"
X    should have an impossible password like "VOID", its home directory
X    should be /usr/lib/cron and its shell should be /bin/sh.  Its group
X    id should be the same as other daemons like "lp".  On my system this
X    is the gid for "other".
X
X(2) Some of the compile-time #defines in cron.h that you may want to
X    change are:
X
X	NUMBJOBS - This determines the maximum number of jobs that the
X	daemon can handle.  Each job takes up 12 bytes in the FIFOs.  In
X	no case should you specify more jobs than the FIFOs can hold.  I
X	set it 400, which seems reasonable to me.
X
X	GRAINULARITY - is the number of seconds that the daemon sleeps
X	each wake/sleep cycle.  The smaller the number the quicker the
X	daemon will see a newly enterred job, but also the more overhead
X	the facility places on the system.  It is set to 60 and probably
X	should stay that way.
X
X	CATCHUP - This is the number of seconds behind "now" that a job
X	can be and still get executed.  AT_JOBs older than this will be
X	automatically removed by the daemon.  The at(1) command will not
X	allow you to enter jobs older than this either.  This parameter
X	has a few twists to it.  When you are enterring a job using the
X	at(1) command, "now" is measured from when you first called at(1).
X	So if it takes you a long time to type in a job, it's possible to
X	have the job refused because it is past CATCHUP (GRAINULARITY is
X	is also taken into account).  Now the daemon is another story.
X	It is possible to get the daemon to execute jobs older than the
X	compile-time CATCHUP parameter.  When the daemon is started, it
X	checks its environment for a shell variable of the same name, and
X	will override the compile-time parameter if there is one.  Also
X	the daemon can be called with a numeric argument on its command
X	line which will override both the compile-time and environment
X	settings.  Here's the reason for this scheme:  Recall that the
X	daemon checks for old jobs in the spool directory when it starts
X	up.  You may want jobs up to, say, 24 hours old executed when it
X	first starts up, but only allow "future" jobs to be enterred with
X	the at(1) command.  So you compile with CATCHUP #defined as 0,
X	but start the daemon with CATCHUP=86400 in its environment.
X
X	MAXKIDS - The daemon will only run this number of jobs on each
X	cycle.  If there are more jobs than this ready, they are pushed
X	ahead to the next cycle.  I #defined this to 10 for compiling.
X	Of course the more jobs the daemon runs at one time the more load
X	it puts on the system.  If you set this parameter too high, the
X	kernal will impose a limit, because it won't let the daemon have
X	any more processes.  Like CATCHUP, the compiled-in value of this
X	parameter can be overridden by using an environment variable or
X	command line argument when starting up the daemon.
X
X	MAXTRIES - Even if the daemon is successful in forking a process
X	to run a job, the system may fail to execute it because the owner
X	of the job is at his/her process limit.  The process will sleep
X	for 10 seconds and try again up to MAXTRIES number of times.  I
X	#defined this as 5 tries, seemed reasonable to me.  The 10 second
X	value is buried in the daemon's code, but it's not hard to find.
X
X	ZEROSECS - If this parameter is #defined, the schedule times you
X	enter with the at(1) command will have their seconds field set
X	to :00.  If it's not #defined, the seconds will be whatever the
X	current clock time's seconds are.  Having seconds = :00 seems
X	more intuitive.  Either way "at now" always uses the current 
X	clock time's seconds (otherwise it would be non-deterministic).
X
X	TZOVRIDE - If this parameter is #defined, the daemon's value for
X	the TZ environment variable will replace the user's value when
X	the job is run.  The reason for this is obscure, but here goes:
X	The environment variable TZ is used to determine whether daylight
X	savings time is in effect at a particular time.  The date of when
X	d.s.t. goes in effect used to be the last Sunday in April, and
X	this is the date compiled into the kernal and standard library.
X	The U.S. Congress has changed the date to the *first* Sunday in
X	April.  If you reset the system clock to compensate, the seconds
X	since Jan 1, 1970 GMT values of all your files and schedules will
X	be wrong.  What you could do is change the timezone instead.  But
X	the value of TZ in a user's job reflects what it was when the job
X	was created, not what it is when it gets executed.  By using
X	TZOVRIDE the TZ variable will get set to the value the daemon gets
X	when it is booted.  This will make things make things work right.
X	The best thing is to get Lenny Tropiano's daylight savings time
X	fix and install that on your system.
X
X	SET_LOGNAME - Normally the at(1) ... crontab(1) commands demand
X	that the LOGNAME environment variable be set correctly.  If this
X	parameter is #defined, the superuser (ie uid=0) gets "LOGNAME=root"
X	put in its environment whenever the usual LOGNAME check fails.
X	This allows you to "su" and use the commands.  Otherwise, you'd
X	have to login as root, use "su -", or setup LOGNAME by hand.
X
X(3) Compile the programs.  Just say "make" or "make all".  I've included
X    a simple makefile with these programs.  I usually compile with the
X    optimizer on, link with the shared library and strip the object files.
X
X(4) Create the following directories on your system if they don't already
X    exist.  Be sure to get owners, groups and permissions right!
X
X    /				root	root	drwxr-xr-x	exists
X    /usr			root	users	drwxr-xr-x	exists
X    /usr/lib			root	bin	drwxr-xr-x	exists
X    /usr/lib/cron		cron	bin	drwx------
X    /usr/spool			root	bin	drwxr-xr-x	exists
X    /usr/spool/cron		cron	bin	drwx------
X    /usr/spool/cron/atjobs	cron	bin	drwx------
X    /usr/spool/cron/crontabs	cron	bin	drwx------
X    /etc			root	sys	drwxr-xr-x	exists
X    /etc/daemons		root	sys	drwxr-x---	exists
X    /usr/local			root	users	drwxr-xr-x
X    /usr/local/bin		bin	bin	drwxr-xr-x
X
X(5) Now move the compiled programs into their proper directories.  Link
X    together at, batch, cronjob and crtabj: they're all the same program.
X    Again, make sure you get the owners, groups and permissions right!
X 
X    /etc/daemons/cron		root	bin	-rwx------
X    /usr/local/bin/at		cron	bin	-rws--x--x	\
X    /usr/local/bin/batch	cron	bin	-rws--x--x	 \ link
X    /usr/local/bin/cronjob	cron	bin	-rws--x--x	 /
X    /usr/local/bin/crtabj	cron	bin	-rws--x--x	/
X    /usr/local/bin/crontab	root	bin	-rws--x--x
X
X    Note: neihter the daemon nor the user commands are tied to any
X    particular directory.  You can put them anywhere you like.  Eg. you
X    could put at and batch in /usr/bin or /usr/lbin if that is the custom
X    on your machine.  I put the daemon in /etc/daemons because anything
X    in /etc/daemons is automatically executed on bootup in the UNIX-PC.
X
X(6) Create and edit the allow and deny files.  Again make sure you get
X    the owner, group and permissions right!
X
X    /usr/lib/cron/at.allow	cron	other	-rw-------
X    /usr/lib/cron/at.deny	cron	other	-rw-------
X    /usr/lib/cron/cron.allow	cron	other	-rw-------
X    /usr/lib/cron/cron.deny	cron	other	-rw-------
X
X	IF XX.allow exists, only those users whose names
X		are in it will be able to use this facilty.
X	ELSE IF XX.deny exists, users whose names are in
X		it will not be allowed to use this facility.
X	ELSE only the superuser will be allowed to use it.
X
X    These files, if used, are one name per line.  If you want to let
X    everybody use the at(1) and batch(1), create an empty at.deny file.
X    Similarly, for the cron.allow and cron.deny files.  An interesting
X    note here is that the code is setup to allow two users to clear the
X    log file: root and cron.  However if you refuse permission to cron
X    with the allowfile-denyfile mechanism, then only root will be able
X    to clean the log file.
X
X(7) Reboot to get the daemon running.  You may want to check the file
X    /etc/rc.  On the UNIX-PC, any programs in /etc/daemons are fired-up
X    automatically from /etc/rc at bootup-time.  If your system uses a
X    different scheme, you may have to add a line such as the following:
X
X		/etc/daemons/cron
X
X    to your /etc/rc file.  You might also want to make use of the CATCHUP
X    feature of the daemon by setting the environment variable or calling
X    the daemon with and argument, like this:
X
X		/etc/daemon/cron 86400	# catchup 24 hours
X
X
X                          ***************
X
X----------------------------------------------------------------
X	Caveats for the Cron Facility - D.Lashomb
X----------------------------------------------------------------
X
XThis cron facility was written for the AT&T Unix-PC model 7300.  I believe
Xit should port well to other sysV machines.  How well it will port to BSD
Xmachines, I don't know.
X
XUsers' login shells:  This facility will work with the Bourne shell (/bin/sh)
Xand the Korn shell (/bin/ksh).  I do not know if it will work with csh.  It
Xwill NOT work with login shells that are scripts - the login shell MUST be
Xa binary executable.  It will NOT work unless the shell can accept the
Xoptions "-c" and "-s" the way /bin/sh does.
X
XWhen the system is booted and the cron daemon starts-up, it checks the jobs
Xin its spool directory.  All jobs are checked for consistency and added to
Xthe daemon's inventory.  CR_TAB jobs are not checked to see if they belong
Xany particular crontab file.  The daemon does not re-parse the crontab files.
XThis *feature* has an advantage in that it allows the user to enter CR_TAB
Xjobs directly with the crtabj(1) command and have them survive a reboot.
XIt has the disadvantage in that spooled CR_TAB jobs have no hard relationship
Xwith the crontab files.
X
XStdout and stderr from users' jobs are mailled to the user using /bin/mail,
Xtherefore /bin/mail must exist on the system.
X
X----------------------------------------------------------------
XNone of the above caveats is insurmountable.  Perhaps some ambitious fellow
Xwill: pepper the code with #ifdef's to make more portable :-)
X
X                          ***************
X
SHAR_EOF
$TOUCH -am 1016164390 README &&
chmod 0644 README ||
echo "restore of README failed"
set `wc -c README`;Wc_c=$1
if test "$Wc_c" != "17482"; then
	echo original size 17482, current size $Wc_c
fi
fi
# ============= Remove ==============
if test X"$1" != X"-c" -a -f 'Remove'; then
	echo "File already exists: skipping 'Remove'"
else
echo "x - extracting Remove (Text)"
sed 's/^X//' << 'SHAR_EOF' > Remove &&
X#    Remove for cron(1M) facility  4/89 D.Lashomb
X
XLOCAL=/usr/local
XBIN=/usr/local/bin
XLIB=/usr/lib/cron
XSPOOL=/usr/spool/cron
XDAEMONS=/etc/daemons
XSRC=$HOME/Filecabinet/SRC
XmySRC=$SRC/Cron
XDOCS=$HOME/Filecabinet/DOCS
XmyDOCS=$DOCS/Cron
X
Xecho "killing the cron daemon"
XI=`ps -e | grep 'cron' | cut -c1-6`
Xfor i in $I
Xdo
X	kill -9 $i
Xdone
Xecho "shall I remove the 'cron' login"
Xecho "from your password file y/[n]? \c"
Xcase "`line`" in
X[Yy]*)	mytmp=/tmp/$$
X	grep -v '^cron:' /etc/passwd >$mytmp
X	cp $mytmp /etc/passwd
X	rm $mytmp
X	;;
Xesac
Xecho "removing my programs"
Xrm $DAEMONS/cron $BIN/at $BIN/batch $BIN/cronjob $BIN/crtabj $BIN/crontab
Xecho "removing my directories"
Xrm -r $LIB $SPOOL
Xecho "shall I remove $mySRC y/[n]? \c"
Xcase "`line`" in
X[Yy]*) rm -r $mySRC ;;
Xesac
Xecho "shall I remove $myDOCS y/[n]? \c"
Xcase "`line`" in
X[Yy]*) rm -r $myDOCS ;;
Xesac
Xecho "Remove done"
Xexit 0
SHAR_EOF
$TOUCH -am 0728232689 Remove &&
chmod 0744 Remove ||
echo "restore of Remove failed"
set `wc -c Remove`;Wc_c=$1
if test "$Wc_c" != "882"; then
	echo original size 882, current size $Wc_c
fi
fi
# ============= Size ==============
if test X"$1" != X"-c" -a -f 'Size'; then
	echo "File already exists: skipping 'Size'"
else
echo "x - extracting Size (Text)"
sed 's/^X//' << 'SHAR_EOF' > Size &&
X500
SHAR_EOF
$TOUCH -am 0728232689 Size &&
chmod 0644 Size ||
echo "restore of Size failed"
set `wc -c Size`;Wc_c=$1
if test "$Wc_c" != "4"; then
	echo original size 4, current size $Wc_c
fi
fi
echo "End of part 1, continue with part 2"
exit 0



More information about the Alt.sources mailing list