ohrnb@edstip.EDS.COM (Erik Ohrnberger) (02/23/90)
I have a question about the safest way to update the cron program's crontab file. What I currently do is update the crontab file, and then rebot the system, to make sure that cron program reads the updated contab file. Is all this required? Does the cron program re-read the crontab file everytime that it wakes up? Is there a special procedure to correctly update the crontab file? Any help would be greatly appreciated. Thank, Erik B-) -- Erik Ohrnberger Work: sharkey!edsews!edstip!ohrnb 2620 Woodchase Court Home: sharkey!nucleus!echocen!erik Sterling Heights, MI 48310 -- Erik Ohrnberger Work: uunet!edsews!edstip!ohrnb 2620 Woodchase Court Home: sharkey!nucleus!echocen!erik Sterling Heights, MI 48310
dan@charyb.COM (Dan Mick) (02/24/90)
In article <855@edstip.EDS.COM> ohrnb@edstip.EDS.COM (Erik Ohrnberger) writes: >I have a question about the safest way to update the cron program's >crontab file. What I currently do is update the crontab file, and then >rebot the system, to make sure that cron program reads the updated contab >file. Is all this required? Does the cron program re-read the crontab >file everytime that it wakes up? Is there a special procedure to correctly >update the crontab file? RTFM. From the SunOS manual on cron: Cron examines /usr/lib/crontab under the following condi- tions: o At least once per hour (on the hour). o When the next command is to be run - cron looks ahead until the next command and sleeps until then. o When cron's process is sent a SIGHUP. This means that someone who changes /usr/lib/crontab can get cron to look at it right away. So update crontab and do "ps ax | grep cron" to get cron's pid, then "kill -HUP <pid>". Of course, this isn't guaranteed to work except on SunOS 3.2; read your man pages to be sure.
rick@comspec.UUCP (Rick McCalla) (02/26/90)
In article <855@edstip.EDS.COM> ohrnb@edstip.EDS.COM (Erik Ohrnberger) writes: > >I have a question about the safest way to update the cron program's >crontab file. Eric : I keep a file called root.crn or rick.crn etc which is a copy of the crontab file I want to use for any user. When I want to modify the crontab file I actually modify the file called root.crn or rick.crn etc. I then su to that user and run 'crontab root.crn' which will replace the crontab for that user with the new one. No need to reboot your system. -- Comspec Communications Inc. | Rick McCalla ----- rick@comspec Toronto, Ontario Canada |---------------------------------- Voice : (416) 785 - 3553 | Path: uunet!mnetor!becker! Fax : (416) 785 - 3668 | comspec!rick
brad@bradf.UUCP (Bradley W. Fisher) (02/26/90)
In article <855@edstip.EDS.COM>, ohrnb@edstip.EDS.COM (Erik Ohrnberger) writes: > > I have a question about the safest way to update the cron program's > crontab file .......... > .... Is there a special procedure to correctly update the crontab file? > According to Rebecca Thomas and Rik Farrow, authors of UNIX ADMINISTRATION GUIDE FOR SYSTEM V (ISBN 0-13-942889-5), page 23 (not *exactly* verbatim but accurate ... BTW this book has many useful tidbits in it) .... $ crontab -l > /tmp/crontab # this lists your crontab to a temporary file [ edit the file /tmp/crontab ... with vi for instance] $ crontab /tmp/crontab # forces cron to read the new crontab file Of course, if you are logged in as root and want to change root's crontab file you'll see a "#" instead of "$" prompt. -- I'm just a wanna be UNIX guru (IJWBUG) | Micro Maintenance, Inc. | 2465 W. 12th St. #6 -== Brad Fisher ==- | Tempe, Arizona 85281 ...!asuvax!mcdphx!hrc!microm!brad | 602/894-5526
jessea@dynasys.UUCP (Jesse W. Asher) (02/28/90)
In article <855@edstip.EDS.COM> ohrnb@edstip.EDS.COM (Erik Ohrnberger) writes: > >I have a question about the safest way to update the cron program's >crontab file. What I currently do is update the crontab file, and then >rebot the system, to make sure that cron program reads the updated contab >file. Is all this required? Does the cron program re-read the crontab >file everytime that it wakes up? Is there a special procedure to correctly >update the crontab file? > The best way to have a crontab entry updated is to create the file, su to the user that the entry will be assigned to, and run a command called "crontab <filename>". For example: If I want to run a UUCP administrative program out of cron, I just create the entry in a file called uucp.cron. If I'm not already logged in as uucp then I use su to do so. I then type in "crontab uucp.cron". The file in /usr/spool/cron/crontabs in automatically updated and cron immediately recognizes the new entry. -- Jesse W. Asher - Dynasys - (901)382-1705 6196-1 Macon Rd., Suite 200, Memphis, TN 38134 UUCP: {uunet,fedeva,rayo}!dynasys!jessea
tr@samadams.princeton.edu (Tom Reingold) (03/01/90)
A few people have responded but may not know that there are two styles of cron. We don't know which the person who asked the question is running. In BSD-style cron, the crontab is checked every minute, so after editing /usr/lib/crontab, nothing is required. 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. With either style cron, no reboot is necessary. -- tr@samadams.princeton.edu
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....
david@llustig.uucp (David Schachter) (03/14/90)
Someone wrote: >>The *only* documented and reliable ways of getting cron to recognize >>a new crontab is to use the crontab command. Or become root, kill cron, change/add/delete crontab stuff, and re-invoke cron. Violent, but effective. Not, perhaps, documented, but reliable. Quite. -- David Schachter llustig!david@mips.com ...!uunet!mips!llustig!david david@llustig.UUCP (MAYBE) Palo Alto, California, USA -- -- David Schachter llustig!david@mips.com ...!uunet!mips!llustig!david david@llustig.UUCP (MAYBE)
donovan@atexnet.UUCP (Dennis Donovan) (03/14/90)
In article <1990Mar14.003245.2932@llustig.uucp> david@llustig.UUCP (David Schachter) writes: >Someone wrote: >>>The *only* documented and reliable ways of getting cron to recognize >>>a new crontab is to use the crontab command. > >Or become root, kill cron, change/add/delete crontab stuff, and re-invoke >cron. Violent, but effective. Not, perhaps, documented, but reliable. Quite. > I just did this the other day. I'm on a Sun 3/60. I updated crontab then sent a Hangup Signal to the cron process with: "kill -HUP ##" where ## is the process ID from "ps" It worked fine!! -------------------------------------------------------------------------------- +----------------------------------------------------------+ | Dennis L. Donovan | | UUCP : !uunet!atexnet!donovan | | AT&T : (617) 276-7349 | | USMAIL : Electronic Pre-Press Systems, Inc (EPPS,ATEX) | | 32 Wiggins Ave., M.S. 231/32W | | Bedford, MA 01730 | +----------------------------------------------------------+ "Nobody asked, just my opinion" Disclaimer: The views expressed are my own, I doubt if ATEX really cares anyway.
guy@auspex.auspex.com (Guy Harris) (03/16/90)
>>>>The *only* documented and reliable ways of getting cron to recognize >>>>a new crontab is to use the crontab command. >> >>Or become root, kill cron, change/add/delete crontab stuff, and re-invoke >>cron. Violent, but effective. Not, perhaps, documented, but reliable. >>Quite. > >I just did this the other day. I'm on a Sun 3/60. I updated crontab then >sent a Hangup Signal to the cron process with: Once again, the fact that there are (at least) two different flavors of "cron" out there leads to confusion.... The first assertion above ("The *only* documented...") applies to the System V Release 2 and later flavor, which appears in some UNIX systems (most, if not all, of those that advertise themselves as S5R2 or later, as well as SunOS 4.x). The second assertion applies (barring a *big* surprise) to all flavors. The third assertion ("I updated crontab then sent a Hangup Signal...") applies to the 4.xBSD "cron" and maybe the V7 "cron" (I no longer have it handy to check), which appears in some UNIX systems (most of those that advertise themselves as 4.xBSD, including SunOS prior to SunOS 4.x which still had "UNIX 4.2BSD" or something like that in its startup message). The first assertion does not apply to the 4.xBSD "cron"; there is no "crontab" command in 4.xBSD. The second assertion does not apply to the S5R2-and-later "cron"; it *ignores* the hangup signal.
clewis@eci386.uucp (Chris Lewis) (03/24/90)
In article <1990Mar14.003245.2932@llustig.uucp> david@llustig.UUCP (David Schachter) writes: > Someone wrote: > >>The *only* documented and reliable ways of getting cron to recognize > >>a new crontab is to use the crontab command. > > Or become root, kill cron, change/add/delete crontab stuff, and re-invoke > cron. Violent, but effective. Not, perhaps, documented, but reliable. Quite. Not. What if something's scheduled to run during the time that cron's dead? Especially if you have to consult the vi manual... ;-) Even su root, change/add/delete, kill cron, /etc/cron may miss *something*. There's still a window of vulnerability, albeit short, but why not do it right and not have to worry about it? I had some code using the kill approach. Worked fine until it missed something rather critical.... Got my buns toasted ... Hell, for automating in scripts, the crontab -l > /tmp/$$ ed - /tmp/$$ <<! ... ! crontab /tmp/$$ is a lot easier than trying to sed/grep/awk cron's pid from ps output. The deficiency in this approach is: a) There is no documented way I've seen in system V to have root read/alter other people's crontabs. Which would be extremely handy especially in the case of (b). AT&T are you listening? Or have I missed something? b) Some vendors make the uucp userid have /usr/lib/uucp/uucico as shell. How're you supposed to "su uucp" and use crontab? Especially those that don't have uucpadm?.... -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list