What is a QUEDEFS file (cron)?

[dcm at sfsup.UUCP]

In Article 12830 at sun.uucp guy at 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 at ihlpa.UUCP> dob at 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 at sun.uucp> guy at 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~