Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ihnp4!mb2c!zeta!gamma!ulysses!sfmag!sfsup!dcm From: dcm@sfsup.UUCP Newsgroups: comp.bugs.sys5 Subject: Re: What is a QUEDEFS file (cron)? Message-ID: <1101@sfsup.UUCP> Date: Mon, 9-Feb-87 14:05:49 EST Article-I.D.: sfsup.1101 Posted: Mon Feb 9 14:05:49 1987 Date-Received: Wed, 11-Feb-87 06:56:08 EST References: <815@investor.UUCP> <1086@sfsup.UUCP> <2897@ihlpa.UUCP> <12895@sun.uucp> Reply-To: dcm@sfsup.UUCP (David C. Miller, consultant) Organization: AT&T Information Systems, Summit, N. J. Lines: 131 In Article 12830@sun.uucp guy@sun.UUCP (Guy Harris) writes: :#>First, a little something about the SysV cron. :#>This is an impressive piece of work! :# :#Yeah, especially impressive bits of code like :# :# while ((n->isdummy) && (n!=NULL)) n = n->right; :# :#Bletch. Somebody ought to sneak in during the night and make the :#"-z" flag the default in the linker, so that the :#null-pointer-dereferencing bugs get caught *before* this stuff gets :#shipped.... :# Well, I never said it was coded well! :-> But the *potential* in the design is impressive. As for the "-z" flag, I couldn't agree more. :# :#>Finally, the '#u' field prevents scheduling of events when the number :#>of users on the system exceeds this number. :# :#Umm, err, I don't see any code to implement that in the S5R3 "cron", :#nor in the S5R2 "cron". There's a #define for USRF, but it's not :#used anywhere. It's in there. Take a look at the function get_batch (assuming you have source). It is about the 3rd or 4th line of code; just look for nuser. In Article <2897@ihlpa.UUCP> dob@ihlpa.UUCP (Daniel O'Brien) flames: :#> Unfortunately, there is no way to use these other queues without :#> rewriting a portion of cron, but that's a story for another day. : :WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG My, my! It sounds like someone got up on the wrong side of the bed this morning! Really Mr. O'Brien, don't you thing one WRONG would have been enough? Or do you routinely flame someone anytime you *think* they're wrong? :You can specify any of the "other" queues by specifying them on the at(1) :command line, as in: : : at -qz now+1hour < jobfile : :would cause the commands in jobfile to be executed "out of" the "z" queue an :hour from now. Um, sorry but no cigar. Using the -q specifier with at causes it to act just like batch. If you want to use the 23 remaining queues for running "batch" jobs, then I suppose it works. I would like to be able to specify different queues (and hence priorities, load, etc) for at and cron jobs not just "batch". Frankly, I have never found a good reason for using batch. The job still runs with my uid, so it is still counted as one of my MAXPROC processes (unless someone has hacked the kernel to limit processes by process group rather than by user id). So I ask, what do I gain by using batch? :> As a closing note, cronjobs (as opposed to atobs or batchjobs) :> bypass the queuedefs. So setting a queue definition for queue 'c' :> will have no effect. :WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG Temper, temper! :Again, you are not correct! Crontab jobs DO NOT BYPASS THE QUEUEDEFS FILE. :You can specify definitions for the "c" queue and all crontab jobs will be run :using them. Yes I was partially wrong on this account. All queuedef option apply except for the 'u' option. This one is bypasswd for cron jobs. :Sorry, but you should get a source license and read the code. I have. Please note my signature; I have read the code. So, I won't get my own source license. Besides at ~60K per license, it's not worth it just to look at cron. By the way, if you read the source, how come you didn't know that "at -qz now+1hour < jobfile" would not work as you claimed? Shame, shame Mr. O'Brien, posting untested code. :-> :-- : Daniel M. O'Brien (ihnp4!ihlpa!dob) : AT&T Bell Laboratories Room IH 4A-257 : Naperville-Wheaton Road, Naperville, IL 60566 In article <12895@sun.uucp> guy@sun.UUCP (Guy Harris) writes: >>Sorry, but you should get a source license and read the code. > >WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG > >Yeah, I've read the source too - I had to, in order to 1) figure out >how the QUEDEFS files worked and 2) fix those damn null-pointer >dereferencing bugs - but it is unacceptable to require somebody to >read the source in order to figure out how an advertised feature >works. > >This stuff was, if I remember correctly, documented in some >transition guide document. As such, I presume the intent was to >advertise this feature. Now neither the original poster nor I can >seem to find it documented anywhere. > >If it *is* documented somewhere, it's in a rather obscure place, and >should probably be moved. If it is *not* documented, then the answer >"get a source license" is totally unacceptable; one should not have >to potentially spend somewhere in the $40-$50K range, and grovel >through the source of "cron", just in order to use "cron" and "at". >The *only* valid fix is to document this stuff or remove it! If it's any consolation, the person responsible for maintaining cron documentation contacted me to ask my opinion on documenting the queuedefs format. My response was, if it's in there it should be documented. 'nuff said. Dave -- David C. Miller, consultant Communications Interface Addresses: Paperware: AT&T Information Systems, 190 River Road, Summit, NJ 07901 Liveware: (201) 522-6107 Software: {allegra,burl,cbosgd,clyde,ihnp4,ulysses}!sfsup!dcm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On good days life is T.A.N.S.T.A.A.F.L. On days like today: T.A.N.S.T.A.A.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~