[cups.general] Broken jobs in queue
Haines Brown KB1GRM
haines at historicalmaterialism.info
Thu Nov 4 10:37:23 PDT 2010
I've newly installed CUPS 1.4.4 in debian squeeze. While lp, a2ps and
my browser have no trouble printing, when I do Print Buffer in emacs,
the job never reaches the printer, even though CUPS returns to its
emacs client the message that "Spooling...done". I have some questions
based on my guesses as to what might be the problem: a) ambiguity over
printer description, b) choice of device interface files, c) whether
no printing due to a permanently active file that can't be processed by
lpd, d) whether CUPS is passing along a broken job to lpd.
Here is the relevant info:
$ lpstat -r
scheduler is running
$ lpstat -p
printer HP_LaserJet_1320_series is idle. enabled since Fri 29 Oct 2010 05:45:46 PM EDT
Printer is now online.
$ lpstat -a
HP_LaserJet_1320_series accepting requests since Thu 28 Oct 2010 02:22:29 PM EDT
$ lpstat -d
system default destination: HP_LaserJet_1320_series
$ sudo /etc/init.d/lpd restart
Stopping printer spooler: lpd.
Starting printer spooler: lpd.
$ cat /etc/printcap
lp|Generic dot-matrix printer entry:\
:lp=/dev/lp0:\
:sd=/var/spool/lpd/lp:\
:af=/var/log/lp-acct:\
:lf=/var/log/lp-errs:\
:pl#66:\
:pw#80:\
:pc#150:\
:mx#0:\
:sh:
1. In settng up CUPS, it sees my HP LayserJet 1320 printer in two ways:
HP_LaserJet_1320_series: usb://HP/LaserJet_1320_series
HP_LaserJet_1320_series: usb://HP/LaserJet_1320_series?serial=00CNL1F33212
I tied both, but have the same problem. Should either work, and if
not, why not?
2. I'm concerned about which device file the printer is
using: /dev/lp0 or /dev/usb/lp0? Shouldn't my USB printer use
/dev/usb/lp0? If so, how does one change that in CUPS?
$ dmesg | grep lp
... On node 0 totalpages: 2096719
... Calibrating delay loop (skipped), value calculated using
timer frequency.. 6666.52 BogoMIPS (lpj=13333040)
... usblp0: USB Bidirectional printer dev 7 if 0 alt 1 proto 2
vid 0x03F0 pid 0x1D17 [ 4.207713] usbcore: registered
new interface driver usblp
... lp0: using parport0 (interrupt-driven).
... usb 1-6.4: usbfs: interface 0 claimed by usblp while 'usb' sets config #1
Is dmesg informative about the question?
# cat /var/log/lpr.log
Nov 1 08:50:38 engels lpd[5756]: restarted
Nov 1 20:34:16 engels lpd[10415]: restarted
Nov 2 08:34:21 engels lpd[1459]: restarted
Nov 2 08:34:21 engels lpd[1479]: /dev/lp0: No such file or directory
Nov 2 09:48:10 engels lpd[1452]: restarted
Nov 2 09:48:10 engels lpd[1454]: /dev/lp0: No such file or directory
Nov 2 15:25:17 engels lpd[1450]: restarted
Nov 2 15:25:17 engels lpd[1482]: /dev/lp0: No such file or directory
Nov 3 09:02:12 engels lpd[4971]: restarted
$ ls /dev | grep lp0
lp0
How can these two reports be reconciled? Why would lpd not see a
device file that is actually there? Is the problem simply that lp0
is busy and inaccessible because of the hung job?
In printcap, I am using /dev/lp0. I tried changing it to
/dev/usb/lp0, but it didn't help.
My ~/.cups/loptions file has:
Default HP_LaserJet_1320_series
but on my previous machine (debian lenny, different hardware), it
was: Default hp_Laserjet_1320_series_USB_1. Is there any difference?
3. Apparently the jobs are stuck in the queue because the first is
active and won't complete:
$ lpq
lp is ready and printing
Rank Owner Job Files Total Size
active haines 53 (standard input) 784 bytes
1st haines 54 (standard input) 784 bytes
...
If I understand correctly, the lpd spool directory is not the CUPS
spool, which is why nothing is returned from this lpstat -W command:
$ lpstat -W not-completed
Incidentally, lpstat -l returns nothing. Shouldn't it list printers
and jobs?
Here are some select lines from the end of the CUPS error_log. No
errors reported:
D [03/Nov/2010:13:18:20 -0400] cupsdCloseClient: 14
D [03/Nov/2010:13:18:20 -0400] PID 5829 (/usr/lib/cups/cgi-bin/admin.cgi) exited with no errors.
D [03/Nov/2010:13:18:20 -0400] cupsdSetBusyState: Not busy
D [03/Nov/2010:13:18:24 -0400] cupsdReadClient: 11 GET /admin/log/error_log HTTP/1.1
D [03/Nov/2010:13:18:24 -0400] cupsdSetBusyState: Active clients
D [03/Nov/2010:13:18:24 -0400] cupsdAuthorize: Authorized as haines using Basic
Does this mean that CUPS is hung up because of the
presence of a permant active file in the lpd queue?
4. In the CUPS interface, for Complete Jobs, all jobs are marked
"completed", whether or not they actually got to the printer, and
there are no active jobs as far as CUPS is concerned, even though
there is an active file in lpd's queue.
In /var/spool/lpd/lp each job has a cf and a df file for it with the
exception of the job that is hung, which has only a cf file and no df
data file.
Is this because a) the df file created by CUPS never made it to the
lpd queue, or b) the point at which the hang occurred was after the
df file had been removed from the queue?. Because lpd has no problem
with a2ps and lp jobs, is the implication that the CUPS job was
broken when it came from CUPS?
The cf file for the hung job looks like this"
/var/spool/lpd/lp/cf053engels
Hengels
Phaines
Jjunk Emacs buffer
Cengels
fdfA053engels
UdfA053engels
N
To my inexperienced eye, I see nothing wrong with it except that it
refers to a non-existent df file.
Haines Brown
More information about the cups
mailing list