Web page 'Jobs' page shows only one job

John A. Murdie john at cs.york.ac.uk
Tue Feb 20 04:59:57 PST 2007


> > John A. Murdie wrote:
> > > A user here has complained that (with CUPS 1.2.5) when he issues
> > > several lp(1) commands in reasonably quick succession, the web page
> > > 'Jobs' list page shows only his top job (for that printer). Only when
> > > that job has been printed does the next one appear in the web
> > > listing. I've reproduced this problem. No report like this is in the
> > > bugs list or in the list of fixes for 1.2.6 and 1.2.7. Is it meant to
> > > work like this?
> >
> > No, you should see all of the pending jobs on the active job list.
> >
> > > Oddly, another CUPS 1.2.5 server we have on another machine does show
> > > multiple entries in a queue for one user - differently-named files.
> > >
> > > Is this something configurable that I might have set incorrectly
> > > without realising it? (But I've searched the cupsd.conf help file
> > > without success.) I can't believe that this is not something silly I
> > > have done.
> >
> > No, I'd guess you are running into something specific to that system.
> > Make sure the two systems have the same software installed...
> >
> > --
> > ______________________________________________________________________
> > Michael Sweet, Easy Software Products           mike at easysw dot com
> > Internet Printing and Document Software          http://www.easysw.com
>

After much casting around and conjecture, I think I finally understand what circumstances are causing this problem. Mike (Sweet), please would you comment on the below? I'd like to eliminate this annoyance, which continues to upset the users here. I now think it's a 'feature' rather than a bug.

The crucial difference between the two CUPS print servers I mention in the original posting of this thread was not - as I conjectured - that one system had had a fresh install and that the other had had its possibly corrupt local state directory carried forward through several different versions, but that I was submitting jobs to the one that behaves oddly through the CUPS server on my desktop Linux system with e.g. 'lpr -P pp23 doc.pdf' and to the other with e.g. 'lpr -H printserver -P pp02s doc.pdf'.  Jobs submitted through the CUPS system on the desktop wait in the local CUPS scheduler spool area until the server has finished with the only job listed on the server Jobs web page, and then another one goes across from the desktop CUPS to the server. Because the users here have been told to use a web browser to view the list of jobs on the server to see the jobs in the queue for a particular workgroup printer, so they can determine when to get up to collect their printout from it, they don't see the jobs waiting on their desktop client to be transferred to the print server. It's natural for them to think that their jobs have not been queued, so they queue them again and again, resulting in multiple copies being printed. Because the jobs don't appear in the queue immediately, some users think their spooled documents have been lost, and fail to go to the printer to collect them at all. It's just not an option to ask the users to have a browser open on localhost:631/jobs and also on printserver:631/jobs, or to have to use `lpq' as well as `lpq -h printserver'. (Incidentally, remembering that it's 'lpr -H' but 'lpq -h' is hard!) They'd be scathing about such a solution.

This problem happens when both server CUPS installations have accsnmp wrapping the real (socket) backend. (Take accsnmp away, and the problem disappears.) I've had a friendly E-mail exchange with Jeff Hardy, the author of accsnmp, and I'm convinced that the problem is not a bug in his software. We need robust, non-static, pagecounting here, as we pass the printing charges on to our students (and staff research groups); a member of staff here showed in the past how with static pagecounting (in an earlier print system) it was possible to print tens of pages in such a way that a charge is made for only one page. (We have to make raw printing available, since we continue to encounter many non-DSC-conforming PostScript documents.) With pagecounting in the printer, all this is not an issue. (I've not tried PyKota, because I have no easy way of obtaining money to pay the 25E accession fee. I'm reluctant to use my own credit card to pay for something for my Department. Since accsnmp does everything we need, very simply, I don't even need to get PyKota free of charge from its CVS repository. We have our own print charging system here which isn't 'broken', so there's no need to 'fix' it with that of PyKota.) I suppose that I shall have to try PyKota just to see if it works around this problem cleverly somehow. Does anyone reading this know whether and how PyKota avoids the problem?

Having the accsnmp backend wrapper wait for a printer to finish a print job before returning a result code apparently causes the CUPS scheduler (on the print server) to hold off spooling other jobs from the client CUPS schedulers for that printer.

A possible solution would be for the desktop printing environment to send jobs for printing directly to the appropriate print server. (We have no desktop PCs with local CUPS printers.) The problem, however, is that we don't want to lose the very nice CUPS feature of printer autodiscovery - it'd be a great hassle to have to reconfigure all our desktop PCs (even if it were possible with one command) each time a printer was retired or added. Neither do we wish to have to name printers e.g. 'pp23 at printserver' - just e.g. 'pp23' is wanted. Is this solution configurable? Alternatively, is there some setting we can make for the CUPS schedulers on the servers to make them accept jobs from client CUPS schedulers immediately, regardless of how far the backend has got with the top 'Processing' job?

John A. Murdie




More information about the cups mailing list