Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
02-15-2009, 04:56 PM
|
#1
|
Senior Member
Registered: Jan 2003
Location: Illinois (SW Chicago 'burbs)
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,849
|
CUPS print queue question
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
|
|
|
02-16-2009, 03:30 PM
|
#2
|
Member
Registered: Oct 2004
Location: Germany
Distribution: Debian
Posts: 274
Rep:
|
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?
|
|
|
02-16-2009, 03:45 PM
|
#3
|
LQ Guru
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,524
|
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.
|
|
|
02-16-2009, 04:08 PM
|
#4
|
Member
Registered: Oct 2004
Location: Germany
Distribution: Debian
Posts: 274
Rep:
|
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
|
|
|
02-16-2009, 04:17 PM
|
#5
|
Senior Member
Registered: Jan 2003
Location: Illinois (SW Chicago 'burbs)
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,849
Original Poster
|
Quote:
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).
|
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.
Quote:
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).
|
Well, I thought that's what I had set up. :-/
Quote:
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)
|
I see (for example):
Code:
lpstat -t
scheduler is running
system default destination: Printer_Name
device for Printer_Name: ipp://192.168.13.177:631/printers/Printer_Name
Printer_Name accepting requests since Mon Feb 16 15:12:22 2009
printer Printer_Name is idle. enabled since Mon Feb 16 15:12:22 2009
Doesn't look out of whack to me. (Well, except for the CUPS team's odd notions about capitalization.)
Quote:
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'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
|
|
|
02-16-2009, 04:34 PM
|
#6
|
Member
Registered: Oct 2004
Location: Germany
Distribution: Debian
Posts: 274
Rep:
|
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.
|
|
|
02-16-2009, 05:34 PM
|
#7
|
Senior Member
Registered: Jan 2003
Location: Illinois (SW Chicago 'burbs)
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,849
Original Poster
|
Quote:
Originally Posted by doc.nice
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.
|
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
|
|
|
02-16-2009, 06:03 PM
|
#8
|
Member
Registered: Oct 2004
Location: Germany
Distribution: Debian
Posts: 274
Rep:
|
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 
|
|
|
All times are GMT -5. The time now is 07:09 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|