Xref: utzoo comp.unix.questions:20536 alt.sys.sun:621
Path: utzoo!attcan!lsuc!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.unix.questions,alt.sys.sun
Subject: Re: crontab update
Message-ID: <1990Mar9.234707.7782@eci386.uucp>
Date: 9 Mar 90 23:47:07 GMT
References: <855@edstip.EDS.COM> <24572@princeton.Princeton.EDU> <EMV.90Feb28121501@duby.math.lsa.umich.edu> <1990Mar1.195750.25818@eng.umd.edu>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Distribution: na
Organization: Elegant Communications Inc., Toronto, Canada
Lines: 52

In article <1990Mar1.195750.25818@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes:
| In article <EMV.90Feb28121501@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
| >In article <24572@princeton.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes:
| >>[crontab description for SunOS 4.0, SysV deleted]
|
| >This is OK but -- I have a bunch of diskless machines with their
| >crontab files all mounted via NFS from a server.  To update the whole
| >batch I need to log in to every machine and run 'crontab' -- if
| >I could automate the procedure somewhat I'd like to.

| Well, you can do some funky things like this:
| cp proto_cron /export/root/client/var/spool/cron/crontabs/root
| rsh client crontab -l

| This will cause cron to re-read the file off of disk.  I would rather
| that cron periodically use stat() the crontab file and re-read it if
| it needed to...

It's by no means certain that "crontab -l" will actually cause cron's
internal tables to change.  It could just as easily be dumping it's
internal tables without reading the file...  Or, reading the file
without updating it's tables.  Further, the permission and ownership 
on the crontab file are rather important, and the copy *may* just lose 
some of them.

This is more in tune with the way crontab expects to be run:

	rsh client crontab -l > /tmp/crontab
	ed /tmp/crontab <<\!
	<insert your updates as ed commands
	!
	rsh client crontab < /tmp/crontab

Though, the rsh's may revoke your userid.

Some of our products automate this sort of thing and they've been working
perfectly for years.

Secondly, as someone else suggested, to *update* a crontab file, you
simply don't create one and jam it in, you should get it *out* first,
for fear that other changes have been made.  (one of our customers did
it this way and kept blowing our product out of the water....)

The *only* documented and reliable ways of getting cron to recognize
a new crontab is to use the crontab command.  Direct editting of the
files will work if you kill cron and restart it.  The permission
requirements and so on make other methods questionable, though many
of them will work *most* of the time.
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list