emv@math.lsa.umich.edu (Edward Vielmetti) (03/01/90)
In article <24572@princeton.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes:
Is SysV-style cron, there is no /usr/lib/crontab. Instead, there are
files called /usr/spool/cron/crontabs/name, where name is a login
name. There is probably a file called root, which is probably what the
guy was talking about if he has SysV-style cron. The crontab(1)
command sends the proper signal to the cron process to reread the
file. It is then kept in memory.
Note that SunOS 4.x has SysV-style cron.
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.
crontab doesn't communicate with signals at least in SunOS 4.x.
It writes something to /var/spool/cron/FIFO, but what? Here's
the trace I got:
open ("/var/spool/cron/FIFO", 05, 037777777776) = 3
write (3, "".., 26) = 26
strings on crontab(1) doesn't help, anyone with sources care
to decode this?
--Edlwall@jato.Jpl.Nasa.Gov (Larry Wall) (03/01/90)
In article <EMV.90Feb28121501@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
: 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.
I suggest you check out the gsh program that comes with perl. It (and gcp
and ged) will let you do things on sets of machines.
gsh all 'crontab -l >/tmp/crontmp'
ged all /tmp/crontmp
s/daily/weekly/;
^D
gsh all 'crontab /tmp/crontmp'
Larry Wall
lwall@jpl-devvax.jpl.nasa.govfalk@peregrine.Sun.COM (Ed Falk) (03/01/90)
In article <EMV.90Feb28121501@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: > >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. Why don't you make all the /usr/spool/cron/crontabs/root files symlinks to /usr/lib/crontab (which you create)? >crontab doesn't communicate with signals at least in SunOS 4.x. >It writes something to /var/spool/cron/FIFO, but what? Here's >the trace I got: > open ("/var/spool/cron/FIFO", 05, 037777777776) = 3 > write (3, "".., 26) = 26 >strings on crontab(1) doesn't help, anyone with sources care >to decode this? I wondered about that. I can edit my crontab at 1410 and set something to go at 1411, and it always works. Cron is certainly finding out about the change right away. Anyway, if you do an 'ls -F' on /var/spool/cron/FIFO, you'll see that it's a named pipe, not a regular file. Clever. -ed falk, sun microsystems sun!falk, falk@sun.com card-carrying ACLU member.
smaug@eng.umd.edu (Kurt Lidl) (03/02/90)
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... -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */
clewis@eci386.uucp (Chris Lewis) (03/10/90)
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
guy@auspex.auspex.com (Guy Harris) (03/13/90)
(Was the "na" distribution on this stuck on automatically by some excessively-helpful posting program, or did some poster along the line genuinely think this was of interest only to North Americans?) >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. The latter is *exactly* what it does, in all the versions I've seen in S5; "cron" doesn't even know that you've *done* a "crontab -l", so it has no effect whatsoever on "cron"s internal tables. >The *only* documented and reliable ways of getting cron to recognize >a new crontab is to use the crontab command. What he said. Don't try to get clever, you'll just outsmart yourself....