[cups.general] how to allow only one job at a time(andqueueeverything else)?

[Kurt Pfeifle]

Tomasz Chmielewski wrote:
> Kurt Pfeifle schrieb:
> 
>> But since you seem to have a very limited environment, with one printer
>> only, it shouldn't be a problem for you to calculatat all possible fil-
>> tering chains for your print clients (which seem to be some kind of MS
>> Windows, guessing from your mentioning of "domain controller".
> 
> Quite the contrary - calculating it can be a bit problematic (or, time
> consuming, and human beings are lazy...).

Given that you're running on ARM, it looks like you build your CUPS
packages yourself.

You could simply change all filters to be the same cost (say, 10) to
make calculations easier, and set the FilterLimit to a value lower than
that..

> The problem is that I have multiple of such devices (these tiny ARM
> running CUPS & friends) in multiple remote locations, with different
> postscript or non-postscript printers (sometimes one printer, sometimes
> more).
> 
> 
>> So (again guessing) the "all possible filtering chains for your print
>> clients" go down to this one alone:
>>
>>   application/postscript
>>              |
>>              |         <----- pstops        # cost : 66
>>              v
>>   application/vnd.cups-postscript
>>              |
>>              |         <----- foomatic-rip  # cost : 100, or whatever
>>              v
>>   application/vnd.cups-raw
>>
>> It's as easy as adding two figures, and then setting the FilterLimit
>> value lower than that. In above example any non-0 equal or smaller than
>> 165 should work.
>>
>> You seem to be an experienced enough user to even find out with 3 or 4
>> "trial and error" tests what a working setting will be for you and your
>> environment.
> 
> It doesn't work that well remotely (well, I could use ps) and for
> devices which are to be deployed in the future ;)

Ah, I thought you had only one such environment to look after...

> In other words: is it safe to set "FilterLimit 1", and expect everything
> to work? 

I guess so.

> (from what you write, it should work though, but I wouldn't
> like to break printing and see CUPS logging "FilterLimit is 1, and this
> job costs 170, rejecting").

It's been a loooooong time since I played with that (and that feature
isn't used or asked for by many people on the mailing list)... but I
don't think you'll see a 'rejecting' message because of this, ever.

The way it worked at the time was this: if any one single job requires
to step across the set FilterLimit, it will do so. However, if that job
is not completed and the next job is to start while the Limit is al-
ready overstepped, that next job is simply put on hold until the first
job is completed.

A rejection would only happen if jobs queue up so fast that they hit
one of the "MaxJobs*" limitations.

> Anyway, I'll deploy a new device to see, but it takes an hour or so.

Can I have one too?   ;-)

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany