[cups] Monitoring concurrent print jobs

[Jörg Thümmler]

Am 20.06.23 um 21:19 schrieb Dave Close:
> I asked:
> 
>> I have a client using CUPS from an application which is licensed
>> according to the number of concurrent print jobs. I think he's paid
>> for more licenses than he actually needs. But trying to discover the
>> actual number of concurrently active jobs (to any printer) has me
>> stymied. The CUPS log files don't seem to provide enough information.
>>
>> It appears that most or all jobs start with a "Create-Job" entry in
>> cups/access_log. Most or all also seem to end with a "Send-Document"
>> entry. But looking through several months of logs, those entries
>> don't balance. I also see "Cancel-Job" entries that don't reference
>> a printer, leaving me wondering. Sometimes I see several consecutive
>> "Cancel-Job" entries where, near as I can tell, there should be no
>> active jobs.
>>
>> Is there a better way to get this information besides parsing the logs?
> 
> =?UTF-8?B?SsO2cmcgVGjDvG1tbGVy?= answered:
> 
>> 1st: looking into my /var/log/cups/access.log I only found balanced
>> Create-job and Send-document entries, always one by one... I remember
>> other entries in times I had some printer troubles, but this should be
>> the normal behavior.
> 
> Looking back about four months, I see 29235 log file entries,
> 12460 Create-Job, 12451 Send-Document, 4255 Cancel-Job. and 69
> others. There's nothing to tie entries together so finding the
> discrepancies would be tedious.
> 
>> 2nd: I would set the variable MaxJobs in cupsd.conf to something large
>> enough. After that you have the jobfiles (and the documents) - on
>> linuxes they should be in /var/spool/cups. Jobfiles are named cXXXXXX,
>> the XXXXXX is the job number. In these jobfiles you found all
>> information about the job, so you can find the job creating user here,
>> which I believe is what you need to separate the jobs of the app. With
>> the time entries in the file there you should be able to find
>> concurrently active jobs, maybe with the "help" of the logfiles entries,
>> although (at least on my system, but maybe it's configureable) you don't
>> find the job number here...
> 
> I hadn't looked at the cXXXXX job files. Now that I have looked, my
> collection only goes back a few days and they aren't easily searched
> using text-based tools as they contain binary field lengths instead of
> line endings. Time fields appear to be binary seconds since the epoch.
> The only tie to access logs is the printer name and the times. Since I
> have so few samples, the effort to parse them doesn't seem worthwhile.
> 

that's why I said "set parameter MaxJobs to something large", mine is 
30000... so you will get enough examples
As for the binary fields - depends on what system you working
for me - on linux - a simple
	
	tr "\000" "\n" <c300159 >c300159a

kills all the null bytes and I can better analyze the content, the 
hardest thing would be the conversion of the timestamps hex strings into 
numbers, but maybe you don't need that exactly ... on the search for 
concurrent print jobs it should be enough if they are equal...

> But I was shocked to see that every one of them reports the printer-uri
> as "ipp://...:631/...". This is shocking because there are no such URIs
> in printers.conf. All printers are defined as "socket://". Although I
> know that all of the printers are capable of handling IPP, converting
> printers.conf is planned but not yet implemented.
> 

all printers are named ipp-printers in the cXXXXXX files. Even the local 
ones. That's because cups handles all printers internally with ipp 
protocol for an example ipp://localhost/printers/p014u3r

> In general, I think the usefulness of CUPS logs could be significantly
> improved. But then, I was hoping someone might have already produced a
> set of tools to deal with them.

AFAIR no one searched for "concurrent print jobs" until now, at least I 
never heard of. Cups itself can handle several print jobs at one time, 
at least I never had a problem with this. The logs are written to find 
errors (and I assume the fact that your "create" and "send"+"cancel" 
entries don't match means you have some here) and the cXXXXXX files are 
stored to repeat a job (which is stored in the corresponding dXXXXXX-YYY 
file, where YYY AFAIK means the repetition count.

I'm not familiar with the windows print system but I'm in doubt you 
would find deeper information here easily

hth
-- 
cu

jth