Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed
On Fri 21 Apr 2017 at 06:05:02 +1000, Ben Finney wrote:
> On 20-Apr-2017, Brian Potkin wrote:
> > Ben - a request. Bug reports below a certain size come through to
> > debian-printing and I get them by SMTP. It is better to compress
> > log files, otherwise I have to go looking for the CC.
>
> I'll try to remember that.
>
> And while we're at it: Thank you for putting in the careful effort to
> troubleshoot this problem with me!
>
> > More testing, I'm afraid.
>
> Bring it on :-)
>
> > Take the file in your $HOME produced by testq. The file utility should
> > identify it as "HP Printer Job Language data".
>
> $ sudo file ~/testq-out
> /home/bignose/testq-out: HP Printer Job Language data
>
> > Send it directly to the printer with
> >
> > cat <printer-ready_file> > /dev/usb/lp0
>
> There is no such device node:
>
> $ find /dev -name 'lp0'
>
> $ ls /dev/usb/lp0
> ls: cannot access '/dev/usb/lp0': No such file or directory
We will come back to this in a moment.
> > Also send the same file with
> >
> > lp -d <SCX-4623 Series queue> -o raw <printer-ready_file>
>
> =====
> $ sudo systemctl restart cups
>
> $ lpstat -a 'SCX-4623-Series'
> SCX-4623-Series accepting requests since Fri 21 Apr 2017 06:00:09 AEST
>
> $ lp -d 'SCX-4623-Series' -o raw ~/testq-out
> request id is SCX-4623-Series-73 (1 file(s))
>
> $ lpstat -a 'SCX-4623-Series'
> SCX-4623-Series accepting requests since Fri 21 Apr 2017 06:00:09 AEST
>
> $ lpstat -o 'SCX-4623-Series'
> SCX-4623-Series-68 bignose 1024 Thu 20 Apr 2017 20:39:29 AEST
> SCX-4623-Series-71 bignose 1024 Thu 20 Apr 2017 20:51:12 AEST
> SCX-4623-Series-72 bignose 95232 Fri 21 Apr 2017 05:56:42 AEST
> SCX-4623-Series-73 bignose 95232 Fri 21 Apr 2017 06:00:24 AEST
>
> $ sudo systemctl stop cups
> =====
>
> > Does it print?
>
> No. The resulting error log (compressed) is attached.
The log is sprinkled with
Waiting for printer to become available.
There are two basic reasons for the printing failure:
1. The usb backend (which uses libusb to send the file to the printer)
has failed. We haven't seen this happen for a long time.
2. A hardware failure. Connecting cable or printer.
We need to send a job without using the usb backend to pin down the
cause. Back to 'cat <printer-ready_file> > /dev/usb/lp0'.
All four of my machines have a file put in /dev/usb/ when a printer is
plugged into a USB port. /dev/usb/ is often created to hold the file. I
am not a USB expert so am only going off a bit of experience. Maybe the
file is lp1. Please would you have a look amd repeat the command. Also,
do 'lpinfo -v' and look for a line beginning 'direct usb://...'.
Cheers,
Brian.
Reply to: