|Tested on openSUSE||Recommended articles||Related articles|
You like to get statistics which user printed how much on which printer.
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.