I have had problems with lpr/lpq/lpd under RH Linux for years. Most of
the time it works fine and then some times it just stops working
mysteriously. Typically after 20 minutes of restarting lpd and playing
with lpq/lprm/lpc and such, it magically starts working. (NOTE - without
fiddling with /etc/printcap!)
I think I figured out the problem today...
I have a network with several (mostly RH Linux, all *nix ) machines and
several printers. The computers share printers with each other. I use
printtool to do all /etc/printcap configuration.
I start by sending a print job from machine1 to its local printer and a
remote printer on machine3. They both work. I send a print job from
machine1 to a remote printer on machine2. Suppose the job is not printed,
but sits in the queue(in my case, machine2 is admin'd by somebody who sucks
and printing doesn't work). (Note I do not see any errors, the job just
sits in the queue). I can still print from machine1 to its local printer
and remote printers. If I now restart lpd using printtool, or by hand
using /etc/rc.d/init.d/lpd stop ... start, printing breaks. I can no
longer print to any printers from machine1, even the local printer (unless
I access the raw device). If I empty the print queue on machine1 for *all*
printers, then restart lpd, printing capabilities are restored for all
printers(except of course machine2 which is broken for other reasons).
I have done a bit of testing of various configurations and this seems to be
fully reproducable on my machines. I have not tested it on an independent
set of machines, but expect it should be reproducable in general.
If lpd really breaks if there is a queue, then it would make sense for lpd
to just clear the queue.
The error given when one tries to print after lpd is restarted with an
existing queue is:
"Error printing test page to queue printername"
"Error reason: lpr: connect: Connection refused"
"jobs queued, but cannot start daemon."
I suspect this is a source of many of the printing problems people report
on the newsgroups and bugzilla.
I would be happy to do further testing/reporting on this issue if
If this is a 15 year old "feature" and everybody but me knows you have to
clear all print queues before restarting lpd, it would be nice if printtool
cleared the print queues automatically. Perhaps even lpd could report -
"You just restarted me with an existing print queue, so I'm not going to
work right. Please empty all print queues and restart lpd."
have you tried to install lpr-0.50-2 from the rawhide directory?
I do have tried lpr-0.50, but it didn't solve the problem. And yes, it looks
like a matter of file presents in the queue directory: if you empty that, all
starts working fine.
I just upgraded a RH 4.2 server to 6.1 and ran into this LPD problem. In my
tinkering I found that if I remove the cf*, df* and lock file from the
/var/spool/lpd/lp directory the first new print job goes through but then
everything stops until I remove the aforementioned files. The odd thing is that
I also resently installed RH 6.1 on a Dell notebook and it doesn't have the same
problem, not that it's that heavily used though.
I am seeing the same problem on RH-6.1. I have also tried using the lpr-0.50-4
from RH-6.2 but the problem persists.
When the queue has hanged, doing "strace lpc start all" shows that lpc is
accessing /dev/printer (and fails) one time for each printer queue, even though
the queues are all remote lpd queues. This behaviour is not observed when I
do "strace lpc start all" when the queue is working.
I have found that printing resumes if I do...
% /etc/rc.d/init.d/lpd restart
% lpc abort all
% lpc start all
When I strace the "lpc abort all" it appears to empty the lock files in the
printer queues. May I offer the suggestion that lpd has a problem with stale
lockfiles and does not gracefully recover when a child lpd dies?
This appears to be the same problem as bug #7488
This is fixed in rawhide with the move to LPRng.
I had same problems.
Has put lpr-0.50-7.5.x they have not disappeared.
It is the last version of the package?