[cups.general] Jobs can't complete

Haines Brown KB1GRM haines at historicalmaterialism.info
Thu Nov 4 10:37:24 PDT 2010


I've newly installed CUPS 1.4.4 in debian squeeze. While lp, a2ps and 
my web browser have no trouble printing, when I do Print Buffer in emacs, 
the job becomes hung in the lpd queue. 

In struggling to resolve this I am left with uncertainties that make 
it difficult: a) CUPS has two names for my HP LaserJet 1320 printer 
and I can't distinguish them. b) I don't know if which I choose 
affects which device interface file should be used. c) I have trouble 
seeing what could be wrong with the job file or printcap that might 
cause it to hang in the queue.


1. 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 a print job is hung and so remains active, and so all subsequent 
  jobs remain in the queue, why do I get no return from this:

	$ lpstat -W not-completed

  Incidentally, lpstat -l also returns nothing. Shouldn't it list 
  printers and hung jobs?

  No errors are reported in the CUPS error_log. 

2. Perhaps a reason for jobs being hung in queue is my printcap file. 
   Here is mine:

        $ 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:
 
  I installed lpr, and it might have created this printcap. I tried 
  without luck changing one line to:

               :lp=/dev/usb/lp0:\

  What program builds this file? If I move it and reconfigure CUPS, 
  will a better printca; be constructed? Will CUPS reconfiguration 
  automatically build a printcap file?


3. In settng it up, CUPS saw my HP LaserJet 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

  This does not seem to refer to two different models of the printer. 
  How does one choose between the two names? I tied both. Are they two 
  names for the same thing?

  My ~/.cups/loptions file names my printer as:

     Default HP_LaserJet_1320_series

  but on my previous machine (debian lenny, different hardware, 
  earlier version of CUPS), it was: Default hp_Laserjet_1320_series_USB_1.

  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.


3. I'm concerned over which device interface file the printer is 
   using: /dev/lp0 or /dev/usb/lp0. Dmesg seems to say that it should 
   be /dev/usb/lp0, but that was not put into printcap. 

	# 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
        Nov  3 09:02:12 engels lpd[4971]: restarted

  Although the device file seems to be present:

	$ ls /dev | grep lp0
        lp0

  How can these two reports be reconciled?


4. I don't know what files I should be seeing in the queue. Although a 
   batch of jobs are stuck in queue, CUPS sees no active jobs.

  In /var/spool/lpd/lp each job has a sf 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 
  queue, or b) at the point at which the hang occurred the df file had 
  already been removed? 

  The fc file for the hung job looks like this"

        /var/spool/lpd/lp/cf053engels
        Hengels
        Phaines
        Jjunk Emacs buffer
        Cengels
        fdfA053engels
        UdfA053engels
        N

  Because lpd has no problem spooling jobs created by a2ps and lp, 
  does that imply the CUPS jobs are broken?


Haines Brown







More information about the cups mailing list