SDB:Printer Accounting

Jump to: navigation, search


Tested on openSUSE

Recommended articles


Situation

You like to get statistics which user printed how much on which printer.

This article is for CUPS up to version 2.x under Linux with the traditional filtering system and backends there.

The nowadays driverless printing workflow is rather different.

Procedure

By default CUPS provides software quota and software page logging, see http://www.cups.org/documentation.php/doc-1.3/accounting.html which reads:

Page logging is only available for drivers
that provide page accounting information,
typically all PostScript and CUPS raster devices.
Raw queues and queues using third-party solutions...
do not have useful page accounting information available.

The CUPS software page logging stores its best-effort/best-guess results into /var/log/cups/page_log - for its file format see http://www.cups.org/documentation.php/doc-1.3/ref-page_log.html and for CUPS 1.4 (i.e. since openSUSE 11.3) see http://www.cups.org/documentation.php/doc-1.4/ref-page_log.html

But software accounting cannot be really reliable. For example see http://otrs.librelogiciel.com/otrs/public.pl?Action=&ID=24 which reads:

Symptom:
You use software accounting but the number
of pages ... is incorrect.
Problem: 	
This is probably because the Page Description
Language generated by your printer driver
is not recognized...
This often happens with custom made drivers...

In particular by printing in "raw" mode via something like

cat printer_specific_data | lp -d queue_name -o raw

any user can bypass all CUPS filtering and therefore also no software accounting program can be run when printing in "raw" mode.

Therefore for "a real count of printed pages" (whatever this actually means, see below) hardware accounting is needed which is - as far as I (User:Jsmeix) know - usually only possible via SNMP for business network printers which maintain an internal reliably working page counter.

Regarding what a "reliably working page counter" may actually mean, see for example the "socket backend pagecounting off by one" mail thread in the cups.general forum: http://www.cups.org/newsgroups.php?gcups.general+T+Q%22socket+backend+pagecounting+off+by+one%22 where a CUPS user reported:

I've done some little tests of the SNMP page counting
in the 1.4.4 socket backend ... see CUPS 1.4.4 socket.c
... when printing N pages, N - 1 pages are ... recorded.
I think that the reason is that ... printers take
some time for the page count to stabilise. 
If I do place an experimental 'sleep(10)' ... in socket.c,
the page count is correct. Naturally, I wouldn't want to
add a useless delay in the socket backend, but some of us
do want reliable, actual, per-job page counts.
I've found that even when these printers report
themselves idle ... the page count is still not stable.

In short: Some printers need several seconds after a print job was finished until their internal page counter had stabilised to the correct value.

But "pages" is not the same as "sheets of paper" so that when printing in duplex mode the number of pages is two times the number of sheets of paper. For example see http://otrs.librelogiciel.com/otrs/public.pl?Action=&ID=32 which reads:

Symptom:  	
Hardware accounting seems to be incorrect
when you print in Duplex mode.
Problem: 	
The printers' internal page counters doesn't
really count the sheets of paper, nor their sides,
but instead the number of times a particular sheet
passes through the paper path.
This means that if you print an odd number of pages
in Duplex mode, the last sheet will be counted
as 2 pages anyway, despite the last page being blank.

Furthermore even an internal reliably working page counter counts all pages or all sheets of paper (depending on how the particular printer's page counter is implemented) but not "only pages with toner on it". For example see http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299582054834+28353475&threadId=347346 which reads:

The printer does indeed count a duplex page
as 2 even if there is not any printing on it.
This is due to the fact that all of the rollers
still have to spin and this cuases wear on the
consumables. In theory you can actually wear out
your toner cartridges/drums etc by simply running
enough blank pages through the units.
Granted, the page count would greatly exceed
the published life expectations but its possible.
Unfortuantely, there is no counter to differentiate
between toner on the page or not.

For more details you may have a look at http://www.pykota.com/

Note that PyKota may require a lot of other software around it so that it can work as you may like to have it in your particular case. Usually openSUSE does not provide packages for all those other software so that you may end up with some new kind of headache regarding printing setup: "Set up a reliably working printer accounting solution."

In most cases the default CUPS software accounting should be sufficient at least to get some kind of reasonable overview how much is printed on which printer by usual Linux users (excluding experts who know how to make printer specific data on their own which they can then print in "raw" mode).

In contrast when there are users who print from Windows to your Linux print server, the default CUPS software accounting is not really useful. The usual way to print from Windows to Linux is that on the Windows client machine the Windows printer driver is run. The driver produces printer specific data which is then printed in "raw" mode on the Linux print server. In this case the default CUPS software accounting cannot count pages. For each "raw" print job there may be none or at most a single entry in /var/log/cups/page_log but the page count value could be only a dummy value "1" regardless how many pages were actually printed.

See also

Portal:Printing

SDB:Printing from Windows to Linux

SDB:Using Your Own Backends to Print with CUPS