I have a system that is acting (among other things) as the network CUPS server (it has a physically attached - via the parallel port - laser printer).

Back before CUPS became the only way to print in Linux, what I used to have was a LPRng print queue on this system. All the workstations on the network had a printcap entry that pointed to this system and would submit jobs to it. If the printer was offline for any reason, jobs would queue up on the print server. The way CUPS seems to insist on doing it is that when the printer is offline, jobs queue up on the workstations. Taking the printer offline and issuing "lpq" shows nothing except the job that was currently printing in the queue. When a print job does complete, the queue remain empty for a bit until (apparently) the CUPS client figures out that it's OK to send another job. It sure looks to me that the queueing is not taking place on the print server.

Is there a way to have jobs continue to be accepted by the CUPS server and queue up on that system rather than on the individual workstations?

Any pointers to informative HOWTOs will be greatly appreciated.


TIA...

--
Rick

On my server, jobs _do_ queue up on the server with the printer attached (well, ok, one of my printers is attached via network, but this is not the point).

My linux workstations have a local cups server running that listens for printer announcements.
The server anounces its printer(s) (i.e. the printer and ppd is only installed and managed on this server) and all clients
show my printer(s).

When a printjob is created on the client, it is sent immediately to the cups server on the "server" machine and also queued there. (check lpstat -t or kcontrol - printers to see the printer device to be something like http://xyz:631/printers/bla or ipp://xyz/printers/bla)

so sorry for the bad news, maybe you have created local printers instead of making the client cups'es listening to the printer announcements of the server?

It doesn't matter where the jobs queue. I know you got used to it a certain way. But local queues are more manageable. There is the problem with canceling a print job on the server machine, unless you alter the cups configuration to allow remote canceling. I simply install printers as ipp://, and they work. You need to specifically turn off advertising if you want a printer to work on only one machine. I can't imagine anything simpler than cups, except maybe MS Windows, and that isn't really a choice.

it does, indeed. When you have >20 users all queuing *local* jobs on their machines and trying several times before giving up just because there is no paper in the printer, it really is not amusing to clear all these local queues instead of just one server queue.

An when you have to update the ppd of the printer? You have to do it on all client machines, instead of just one server machine...

nevertheless, thats not the question, the question is "why does it happen"?


NOM and good night,
Florian

So I take it that when you issue "lpq" on the CUPS server, you'll see more than one job listed. What I currently see is a single job: the one that is actively printing. When I know there's more than one job waiting to print, I never see those pending jobs sitting out in the queue. Those jobs never seem to be visible to "lpq" on the CUPS printer server until they dribble in from the CUPS clients. It seems like the CUPS server is doing nothing more than glorified XON/XOFF flow control instead of accepting print jobs into its queue. Not what I'm looking for.

Well, I thought that's what I had set up. :-/

I see (for example):Doesn't look out of whack to me. (Well, except for the CUPS team's odd notions about capitalization.)

It's quite possible that's what I wound up doing. I recently did some rejiggering of the CUPS configuration to force the CUPS server to use the printer's toner saver mode by default. The goal was to not eat through another US$90+ cartridge as quickly as the last one. Anyone who really needed high quality printing was suppose to override the default from their local CUPS client when they really needed it. That's when I noticed that the queueing wasn't working as I expected. It is entirely possible, though, that it's always been acting the way I'm seeing.

Is what I'm trying to do with printer defaults the cause of the queueing problem? Is what I'm trying to do even possible under CUPS?

Any tips are greatly appreciated. As usual, TIA...

--
Rick

The defaults should work fine even when the printers are defined only on the server
(but I haven tested this one, as my $HOMES are nfs homes coming from the same server...)

you could check if you have created local printer queues by simply pulling the eth plug of a client _before_ booting.
it should not show any printer using lpstat.
When you plug the network in, the printer should show up (with some delay up to 5 mins). You can restart the client's cups server process to force a printer query over the network to shorten this time to "nearly 0".

but guessing from the lpstat output you posted, this loooks fine except you have locally created a printer named Printer_Name and set its interface to use ipp://192.168.13.177:631/printers/Printer_Name

PS: if I understood the cups manual right, the options may also be for a reomte printer (http://www.cups.org/doc-1.1/sum.html#SAVING_OPTIONS)
if you use kde, you can try the "kcontrol" printer gui, it makes managing printers _really_ comfortable.

That's what was driving me batty. I was doing exactly what you described and wanted to prohibit jobs from printing until I had the printer back up and working properly and kept having remote print jobs jumping onto the printer. There were several workstations that had queued up jobs but were totally invisible to me at the server.

If what I'm encountering is going to become standard procedure for UNIX print queues, I weep for the poor administrator that has dozens and dozens of workstations that all want access to the sole color printer in the department that's on the fritz and who needs to barge into their offices to halt their local print queues. And then later enable them again. And, silly me, here I thought CUPS was supposed to be a new enterprise-level print "solution" for Unix. I'm actually hoping it turns out that way. But for now my love/hate relationship with CUPS is heavily tilted to the "hate" side.

Still awaiting enlightenment as to the means of having all that disk space on the print server become useful as a print queue.

--
Rick

check /etc/cups/printers.conf: on the clients, this file should _not_ define any printers, else you will run when you want to stop your jobs