[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