dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/23/88)
I just sent DCRON off to the moderator. It has been extensively tested. It requires the recently posted NULL: device to work (a NULL: binary will be packaged with it). DCRON solves the world's problems. It is crontab file compatible with AmiCron (I looked at AmiCron as a reference, then wrote DCRON about from scratch). The major feature is that it does not scan the file every minute, but calculates how long it must wait till the next scan. (A further refinement would be to read in the file into memory and not scan it at all from disk unless it was modified, but unless you do something every minute the extra memory taken up may not be worth it). It is generally intelligent about most things. Credit to Rick Schaeffer and his AmigaCron, whos source I skimmed before writing this. -Matt P.S. I lied when I said DCRON solves the world's problems.
rsb@dukeac.UUCP (R. Scott Bartlett) (12/23/88)
In article <8812230336.AA06015@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > The major feature is that it does not scan the file every minute, >but calculates how long it must wait till the next scan. This doesn't allow one to modify the crontab file and expect cron to pick up on the changes immediately (well, a minute later). With DCRON, if you modify the crontab, DCRON won't realize the change untill it has to do something from the old crontab. I don't mind AmiCron polling the disk every minute at all; in fact, i use this feature to my advantage to know when the HD buffers have been flushed so that i can reboot (but that's beside the point). >(A further refinement >would be to read in the file into memory and not scan it at all from disk >unless it was modified, but unless you do something every minute the extra >memory taken up may not be worth it). I think that this might be worth it, in some form or another. rsb -- rsb@dukeac.ac.duke.edu /// "Amigas do it with hardware."-- Me rutgers!mcnc!ecsvax!dukeac!rsb /// "Sycamore is open."-- Negativ Land I'm a HORSE, of course. \\\/// "I luv S&M!!!" "No geeks here!!" Disclaimer NOT included! \XX/ "This space for rent"
eric@hector.UUCP (Eric Lavitsky) (12/24/88)
In article <1176@dukeac.UUCP> rsb@dukeac.UUCP (R. Scott Bartlett) writes: >In article <8812230336.AA06015@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > This doesn't allow one to modify the crontab file and expect cron to >pick up on the changes immediately (well, a minute later). With DCRON, if you >modify the crontab, DCRON won't realize the change untill it has to do something >from the old crontab. I don't mind AmiCron polling the disk every minute at >all; in fact, i use this feature to my advantage to know when the HD buffers >have been flushed so that i can reboot (but that's beside the point). > >>(A further refinement >>would be to read in the file into memory and not scan it at all from disk >>unless it was modified, but unless you do something every minute the extra >>memory taken up may not be worth it). >I think that this might be worth it, in some form or another. The easy way to do this is as follows: If the "cron" is run a second time, have it send a signal to the cron that is already running and then exit. This signal will tell the running copy to read the table again. So, you make a change to the table and run cron again. This simply signals the cron which is already running and then exits. DropCloth worked in a similiar fashion to kill itself if it found it was already running. This eliminates the need for seperate commands or switches to do this sort of stuff... -Eric ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com UUCP: {att,ucbvax}!ulysses!eric or {wherever!}rutgers!topaz!eric SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854 "To err is human; To really f*ck up requires the root password."
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/24/88)
:ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com :>>memory taken up may not be worth it). :>I think that this might be worth it, in some form or another. : :The easy way to do this is as follows: : : If the "cron" is run a second time, have it send a signal to the : cron that is already running and then exit. This signal will tell the : running copy to read the table again. : :So, you make a change to the table and run cron again. This simply signals the :cron which is already running and then exits. DropCloth worked in a similiar No need. DCron checks the file timestamp every minute (this takes essentially 0 CPU), and if it changes it aborts its (possibly long) timeout for the normal scan and forces one immediately. >fashion to kill itself if it found it was already running. This eliminates >the need for seperate commands or switches to do this sort of stuff... > >-Eric Good idea for a different reason. Kim actually suggested that to me (not allowing two cron's to run at the same time) but I forgot to add it. -Matt
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/24/88)
:In article <8812230336.AA06015@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
:> The major feature is that it does not scan the file every minute,
:>but calculates how long it must wait till the next scan.
: This doesn't allow one to modify the crontab file and expect cron to
:pick up on the changes immediately (well, a minute later). With DCRON, if you
:modify the crontab, DCRON won't realize the change untill it has to do something
:from the old crontab. I don't mind AmiCron polling the disk every minute at
Sorry, I should have explained DCron's intelligence a bit more.
DCron *DOES* check the file's timestamp every minute, just doesn't scan
the file every minute (unless the timestamp has changed). Doing a Lock/
Examine takes virtually no CPU as the block in question is already cached
from previous Lock/Examine's.
-Mattlphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/25/88)
In <1176@dukeac.UUCP>, rsb@dukeac.UUCP (R. Scott Bartlett) writes: >> The major feature is that it does not scan the file every minute, >> but calculates how long it must wait till the next scan. > This doesn't allow one to modify the crontab file and expect cron to > pick up on the changes immediately (well, a minute later). With DCRON, if you > modify the crontab, DCRON won't realize the change untill it has to do something > from the old crontab. One way to do it would be to have a cron create a public message port. When you ran it, it would look for this port, and if present, send a message to it and exit. The message could mean 'update crontab', 'quit', or anything else, perhaps based upon a command line argument. > I don't mind AmiCron polling the disk every minute at > all; in fact, i use this feature to my advantage to know when the HD buffers > have been flushed so that i can reboot (but that's beside the point). The same purpose is served by waiting 3 seconds after the last write. >> (A further refinement >> would be to read in the file into memory and not scan it at all from disk >> unless it was modified, but unless you do something every minute the extra >> memory taken up may not be worth it). > I think that this might be worth it, in some form or another. Definitely. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/25/88)
In <8812232110.AA01833@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >:ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com >:>>memory taken up may not be worth it). >:>I think that this might be worth it, in some form or another. >: >:The easy way to do this is as follows: >: >: If the "cron" is run a second time, have it send a signal to the >: cron that is already running and then exit. This signal will tell the >: running copy to read the table again. >: >:So, you make a change to the table and run cron again. This simply signals the >:cron which is already running and then exits. DropCloth worked in a similiar > > No need. DCron checks the file timestamp every minute (this takes >essentially 0 CPU), and if it changes it aborts its (possibly long) timeout >for the normal scan and forces one immediately. So you're back to going to disk anyway by looking at the timestamp. There are two reasons I'm not fond of the crons I've seen so far. One is the reuirement for a window, and the other is that it goes to disk. If you are going to disk anyway, you may as well read the crontab again. Looking forward to seeing it. Looks like it is on the right track. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/27/88)
:> No need. DCron checks the file timestamp every minute (this takes :>essentially 0 CPU), and if it changes it aborts its (possibly long) timeout :>for the normal scan and forces one immediately. : : So you're back to going to disk anyway by looking at the timestamp. : : There are two reasons I'm not fond of the crons I've seen so far. One is the :reuirement for a window, and the other is that it goes to disk. If you are :going to disk anyway, you may as well read the crontab again. : : Looking forward to seeing it. Looks like it is on the right track. : :-larry No No, even with only 5 buffers, the two that are needed for the Lock/Examine are most likely cached after the first try. And, of course, when it *does* access the disk it's only to read a sector or two... it only writes (updates the log) when there is actually something to do, and unless you have a * * * * * * entry which is run every minute, this doesn't happen often. And people ask me if I'm a patient person ... Actually, the problem is probably due to network propogation times (or people not reading their news backwards... ALWAYS read your news messages from the end to the beginning so you don't make too many redundant replies!). -Matt
dale@boing.UUCP (Dale Luck) (12/28/88)
In article <1176@dukeac.UUCP> rsb@dukeac.UUCP (R. Scott Bartlett) writes: >In article <8812230336.AA06015@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >> The major feature is that it does not scan the file every minute, >>but calculates how long it must wait till the next scan. > This doesn't allow one to modify the crontab file and expect cron to >pick up on the changes immediately (well, a minute later). Not really knowing how arex works, maybe this would solve the problem. Maybe put an arex port in the dameon, send an arex command to it after editing the crontab, telling it to reread the crontab file. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
sean@ms.uky.edu (Sean Casey) (12/28/88)
In article <548@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: [regarding DCRON] >Maybe put an arex port in the dameon, send an arex command to it after >editing the crontab, telling it to reread the crontab file. This would be really cool, as soon as CA releases AREXX along with AmigaDos. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``My name is father. You killed my die. Prepare to Inigo Montoya.''
ewhac@well.UUCP (Leo L. Schwab) (12/28/88)
In article <8812262323.AA20514@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >ALWAYS read your news messages from the end to >the beginning so you don't make too many redundant replies!). > Actually, I read my news beginning to end using 'rn', hitting 'm' on those articles I'd like to [f]ollowup or [r]eply to later on. If I find someone else has already made the statement I wanted to make, then I don't bother to actually respond to them when I review them the second time. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/29/88)
In <8812262323.AA20514@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:> No need. DCron checks the file timestamp every minute (this takes >: So you're back to going to disk anyway by looking at the timestamp. > No No, even with only 5 buffers, the two that are needed for the >Lock/Examine are most likely cached after the first try. And, of >course, when it *does* access the disk it's only to read a sector or two... >it only writes (updates the log) when there is actually something to do, and >unless you have a * * * * * * entry which is run every minute, this doesn't >happen often. I don't know about your setup and operating methods, but I use my machine a lot. I'd be willing to bet that after starting cron in a startup-sequence, I'd lose that cached data in a matter of minutes, due to all the other activity. Was there any real objection to reading crontab into memory and using a message to signal an update? (I'm not asking you to do it, just wondering if there are any pitfalls I haven't thought of) > And people ask me if I'm a patient person ... Actually, the >problem is probably due to network propogation times (or people not reading >their news backwards... ALWAYS read your news messages from the end to >the beginning so you don't make too many redundant replies!). Sorry about that.. I usually pay better attention. > -Matt -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/30/88)
:> No No, even with only 5 buffers, the two that are needed for the :>Lock/Examine are most likely cached after the first try. And, of :>course, when it *does* access the disk it's only to read a sector or two... :>it only writes (updates the log) when there is actually something to do, and :>unless you have a * * * * * * entry which is run every minute, this doesn't :>happen often. : :I don't know about your setup and operating methods, but I use my machine a :lot. I'd be willing to bet that after starting cron in a startup-sequence, I'd :lose that cached data in a matter of minutes, due to all the other activity. <sigh>. .. People are still not thinking! If you use your disk enough that the cached data is lost, at the time dcron comes around and does the lock/examine you'll get a disk access and it will be cached again. Since you are using your disk a lot anyway this extra access will not be noticed. On the otherhand, if you are not using your disk at all the cached data is not lost and thus dcron makes no disk accesses. Now, before we continue this argument why doesn't somebody *TEST* the perceived problem using dcron, ok? -Matt
rminnich@super.ORG (Ronald G Minnich) (12/31/88)
In article <10748@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >This would be really cool, as soon as CA releases AREXX along with AmigaDos. Well, looking at 1.3 amigabasic disk reveals that it is the same piece of microsoft crap that came with 1.1. Slow, buggy, crashes my machine, etc. Now if C= would distribute arexx with 1.4, and jack the price by, say, $10 or so, i wonder if that would make William Hawes interested. It would guarantee a certain volume (what, 500,000 copies??) that might make up for the difference in price for arexx. I sure would like to see arexx take the place of amigabasic in the distribution. Amigabasic is another one of the standard programs that just make the Amiga look bad. And with arexxlib arexx now has menus and graphics too. Just food for thought, I hope someone at C= at least thinks about this. One nice thing about c= is that they have been willing to send out 3d party software in the 1.3 enhancer. ron
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/31/88)
In <8812292136.AA14633@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Now, before we continue this argument why doesn't somebody *TEST* >the perceived problem using dcron, ok? Well, I am not trying to argue (were you?). I see the package came through, so I'll just take a look at it and make the changes. I do not like it to go to the disk unnecessarily. You don't mind. To each his own. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
stan@teroach.phx.mcd.mot.com (Stan Fisher) (04/08/89)
Has anybody had any problem with the recent release of
AmigaUUCP's DCRON? I have my 2500 poll two different sites at
different times through the day, and they almost always get polled
1 hour and 1 minute after the time set in my 's:crontab' file.
Other functions of my crontab like log file clean up etc.
either don't get done at all or are done late. Once in a while it
will do the function at the correct time and other times it does them
both at the correct time AND 1 hour,1 minute late, in other words twice
for the same cron entry.
I've tried several different ways of setting up the crontab,
I've also tried it on the 68k side of the system in case it was an
'020 problem.
Other than this inconvenient little problem, I find the
AmigaUUCP 0.50 package absolutely FANTASTIC. (yes I realize the DCRON
program is separate from the actual AmigaUUCP, just included on the disk)
Stan Fisher asuvax!mcdphx!teroach!stan
Motorola Microcomputer Division, Tempe, Arizona - (602) 438-3228sneakers@heimat.UUCP (Dan "Sneakers" Schein) (04/09/89)
In Message <10676@mcdphx.phx.mcd.mot.com>, stan@teroach.phx.mcd.mot.com (Stan Fisher) writes: > Has anybody had any problem with the recent release of >AmigaUUCP's DCRON? I have my 2500 poll two different sites at >different times through the day, and they almost always get polled >1 hour and 1 minute after the time set in my 's:crontab' file. > Other functions of my crontab like log file clean up etc. >either don't get done at all or are done late. Once in a while it >will do the function at the correct time and other times it does them >both at the correct time AND 1 hour,1 minute late, in other words twice >for the same cron entry. > I've tried several different ways of setting up the crontab, >I've also tried it on the 68k side of the system in case it was an >'020 problem. Sounds much like the results I had with Dcron. After trying to solve the problems I finally packed it in and went back to using AmigaCron included with Amiga UUCP/UseNet V0.40 - V0.42 Sneakers -- ___ Dan "Sneakers" Schein //// BERKS AMIGA BBS Sneakers Computing //// 60+ Megs of software & messages 2455 McKinley Ave. ___ //// 12/2400 Baud - 24 Hrs West Lawn, PA 19609 \\\\ //// 215/678-7691 \\\\//// {pyramid|rutgers|uunet}!cbmvax!heimat!sneakers
thad@cup.portal.com (Thad P Floryan) (04/10/89)
Re: Stan's comments about AmigaUUCP version 0.50 ... (fantastic product) .. yeah, but ... Have you noticed uucico doesn't believe in direct connections? Just TRY and specify a direct connection in your L.sys file and see how far you get; it insists on sending "ATDT crapola" out the serial port. Not nice when the machine to which you want to connect is flanking the Amiga and can be connected to at 19,200 with everything ELSE except AmigaUUCP. Fixing and recompiling the sources won't work without a (recent) Lattice compiler. :-( Thad Floryan [thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad]
noel@uokmax.UUCP (Bamf) (04/12/89)
In article <16957@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >Re: Stan's comments about AmigaUUCP version 0.50 ... > >(fantastic product) .. yeah, but ... > >Have you noticed uucico doesn't believe in direct connections? Just TRY and >specify a direct connection in your L.sys file and see how far you get; it >insists on sending "ATDT crapola" out the serial port. Not nice when the >machine to which you want to connect is flanking the Amiga and can be >connected to at 19,200 with everything ELSE except AmigaUUCP. I encountered this problem, but considered it only a minor inconvienence. To make this work, I made the program dial the number 2, and then in my starting directory on the host, I made a file called ATDT2 that was a shell script that returned the string "CONNECT", and started uucico. Works like a charm... -- Bamf -- NEVER date a music major. At least not one that's named her clarinet "Thor" ----You want it should sing too?------| noel@uokmax | ngorelic@uokmax <Dis-Claimer, Dat-Claimer, to look at | uokmax!tavern!anyone 'em, you'd never know the diff...> | "Beam me up Scotty, we're outta beer"