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.
