crontab update
Chris Lewis
clewis at eci386.uucp
Sat Mar 10 09:47:07 AEST 1990
In article <1990Mar1.195750.25818 at eng.umd.edu> smaug at eng.umd.edu (Kurt Lidl) writes:
| In article <EMV.90Feb28121501 at duby.math.lsa.umich.edu> emv at math.lsa.umich.edu (Edward Vielmetti) writes:
| >In article <24572 at princeton.Princeton.EDU> tr at 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
More information about the Comp.unix.questions
mailing list