root@investor.UUCP (02/02/87)
When I set up /usr/lib/cron/log on my system, each command is
preceded by the following:
! cannot stat QUEDEFS file current date and time
I cannot find a reference to this file anywhere in the manuals.
Anybody know what it is and how to set it up?
--
Bob Peirce, Pittsburgh, PA
uucp: ...!{allegra, bellcore, cadre, idis}
!pitt!darth!investor!rbp
412-471-5320
NOTE: Mail must be < 30K bytes/messagedcm@sfsup.UUCP (02/04/87)
In article <815@investor.UUCP> root@investor.UUCP writes: >When I set up /usr/lib/cron/log on my system, each command is >preceded by the following: > >! cannot stat QUEDEFS file current date and time > >I cannot find a reference to this file anywhere in the manuals. >Anybody know what it is and how to set it up? First, a little something about the SysV cron. This is an impressive piece of work! The cron daemon has the capability of maintaining 26 different event queues. Presently only 3 are being used. Queue 'a' is for 'at(1)' jobs, queue 'b' is for 'batch(1)' jobs, and queue 'c' is for cron jobs. (For those not running SysV, saying "batch" is almost like saying "at now", but it uses a different queue and at would respond with "at: too late".) So, that means that there are 23 queues presently unused. Unfortunately, there is no way to use these other queues without rewriting a portion of cron, but that's a story for another day. Now, regarding QUEDEFS. This is in reference to the file "/usr/lib/cron/queuedefs". This file defines certain aspects of the event queues. The default contents should look something like: $ cat /usr/lib/cron/queuedefs a.4j1n b.2j2n90w $ The format of these lines is "queue.[#j][#n][#w][#u]". Queue is the name of one of the queues ('a' thru 'z'). The four fields following the period are all optional. The '#' represents an integer decimal value. The '#j' field limits the number of concurrently running jobs permitted for that queue. The '#n' specifies the nice for all non su jobs on that queue. The '#w' field specifies how long to wait, in seconds, before rescheduling when the number of running jobs is >= '#j'. Finally, the '#u' field prevents scheduling of events when the number of users on the system exceeds this number. A zero value means no restriction. The default values are "10j2n60w0u". 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. Dave -- David C. Miller, consultant Communications Interface Addresses: Paperware: AT&T Information Systems, 190 River Rd B-310, 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
guy@gorodish.UUCP (02/05/87)
>! cannot stat QUEDEFS file current date and time > >I cannot find a reference to this file anywhere in the m
guy@gorodish.UUCP (02/06/87)
>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.... Also, I'd be curious to see how it stacks up against other batch systems, like MDQS. >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.
dob@ihlpa.UUCP (02/06/87)
#> First, a little something about the SysV cron. #> This is an impressive piece of work! The cron daemon has the #> capability of maintaining 26 different event queues. Presently #> only 3 are being used. Queue 'a' is for 'at(1)' jobs, queue 'b' #> is for 'batch(1)' jobs, and queue 'c' is for cron jobs. (For those #> not running SysV, saying "batch" is almost like saying "at now", but #> it uses a different queue and at would respond with "at: too late".) #> So, that means that there are 23 queues presently unused. #> 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 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. > 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 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. Furthermore, all queues can have a queue definition. Jobs submitted to a particular queue would get those specifications, or if not set in the queuedefs file, they get the default specifications. Sorry, but you should get a source license and read the code. I have. > Dave -- Daniel M. O'Brien (ihnp4!ihlpa!dob) AT&T Bell Laboratories Room IH 4A-257 Naperville-Wheaton Road, Naperville, IL 60566
guy@gorodish.UUCP (02/08/87)
>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!geller@eli.UUCP (02/08/87)
In article <2897@ihlpa.UUCP>, dob@ihlpa.UUCP (Daniel M. O'Brien) writes: > Sorry, but you should get a source license and read the code. I have. Oh, gee! Is AT&T having a special or something. If the price drops a little I might try. But I'm $66,000 short right now. Is there a payment plan available? David Geller
dcm@sfsup.UUCP (02/09/87)
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tank@apc3b2.UUCP (02/11/87)
Price of source for commercial users went up to $65K. And to $800 for
Educational instutions (yes that is eight hundred dollars ;-(
It needs to be documented somewhere, and those with source need to tell AT&T
about the bugs. Us'ns sans source can't hack changes, *sigh*.
-tank-
--
Jon A. Tankersley | Usenet: { ... }!okstate!apc3b2!tank
Amoco Corporation | Voice: (918) 581-4086
PO Box 591, MS N1068 | Disclaimer: My own opinions.
Tulsa, Oklahoma, 74013 | guy@gorodish.UUCP (02/12/87)
>Well, I never said it was coded well! :-> But the *potential* in the >design is impressive. Other such systems have been done, with fewer funny little non-orthogonalities (Why does only one queue provide ASAP job execution? Would it not make more sense to support "execute ASAP" and "execute ASAP after this time" jobs in all queues?) and more generality (Might it not be useful to have queues that run some specified program, such as "troff", with the job file used as input? Might it not also be useful to support submission of jobs to other machines' queues - e.g., a bunch of workstations hanging off some supercomputer or mini-supercomputer?) In short, It's Been Done Before (although not always under UNIX), and arguably better. >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. I have source. Unfortunately, it's only the source to the standard S5R2 and S5R3 "cron", not the version you're talking about; it has no such function in it, and doesn't support the "u" parameter in "queuedefs" files. >:#> Unfortunately, there is no way to use these other queues without >:#> rewriting a portion of cron, but that's a story for another day. This is wrong. I just ran a job in queue "d", after setting up a "queuedefs" entry for it. >Um, sorry but no cigar. Using the -q specifier with at causes it to act just >like batch. Um, sorry, but no cigar. *Only* jobs in queue "b" are executed ASAP, at least in the standard version. It waited until the specified time before executing the job I ran in queue "d". >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? It's less a question of what you gain than of what the system gains. If you have a reasonably cooperative user base, and a machine that could be swamped if everybody who wants to do a "make" or "troff" or whatever does it, you can reduce thrashing of various flavors by running those jobs in a batch queue. I know of one Data General AOS site that did that, and was told by an ex-DG person that this was done at DG as well. Multics also had variants of the standard compiler commands that ran the compilation as a batch job. It may also be useful for machines like the aforementioned supercomputers, where you may not want a high level of multiprogramming. >:> 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. If you're looking for some amusement, try submitting an "at" job to queue "c" and watch the sparks. "cron" thinks that everything in that queue is a "cron" event, so it assumes that the data structures are set up properly for a "cron" event - even if the event was entered by "at". They should not have introduced this "queue 'c' is for 'c'ron jobs" nonsense, and had a separate file for the at/batch queues' parameters and the parameters used for "cron" jobs. (They should also have had all the at/batch queues support both "execute ASAP" batch jobs and "execute ASAP after a specified time" at jobs and permitted them to have multi-character names.)