Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed
258 views
Skip to first unread message
Ben Finney
Apr 18, 2017, 8:50:03 PM4/18/17
to
Package: cups-daemon
Version: 2.2.1-5
Version: 2.2.2-2
Severity: normal
When attempting to print via CUPS, the job will successfully enter the
queue (the status “Processing” is shown). Then, the job is shown as
“Stopped”; the queue does not progress.
When I then attempt to remove that job – or any job – it simply fails.
The print queue is currently unusable, and its jobs remain there,
stopped.
I am using GNOME 3's printer management.
-- System Information:
Debian Release: 9.0
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cups-daemon depends on:
ii adduser 3.115
ii bc 1.06.95-9+b3
ii dpkg 1.18.23
ii init-system-helpers 1.47
ii libavahi-client3 0.6.32-2
ii libavahi-common3 0.6.32-2
ii libc6 2.24-9
ii libcups2 2.2.2-2
ii libcupsmime1 2.2.2-2
ii libdbus-1-3 1.10.18-1
ii libgssapi-krb5-2 1.15-1
ii libpam0g 1.1.8-3.5
ii libpaper1 1.1.24+nmu5
ii libsystemd0 232-22
ii lsb-base 9.20161125
ii procps 2:3.3.12-3
ii ssl-cert 1.0.38
Versions of packages cups-daemon recommends:
ii avahi-daemon 0.6.32-2
ii colord 1.3.3-2
ii cups-browsed 1.13.4-1
Versions of packages cups-daemon suggests:
ii cups 2.2.2-2
ii cups-bsd 2.2.2-2
ii cups-client 2.2.2-2
ii cups-common 2.2.2-2
ii cups-filters [foomatic-filters] 1.13.4-1
ii cups-ppdc 2.2.1-8
ii cups-server-common 2.2.2-2
ii foomatic-db-compressed-ppds [foomatic-db] 20161201-1
ii ghostscript 9.20~dfsg-3
ii hplip 3.16.11+repack0-2
ii poppler-utils 0.48.0-2
ii printer-driver-cups-pdf [cups-pdf] 2.6.1-22
ii printer-driver-gutenprint 5.2.11-1+b2
ii printer-driver-hpcups 3.16.11+repack0-2
pn smbclient <none>
ii udev 232-22
-- no debconf information
--
\ “We have to go forth and crush every world view that doesn't |
`\ believe in tolerance and free speech.” —David Brin |
_o__) |
Ben Finney <big...@debian.org>
Version: 2.2.1-5
Version: 2.2.2-2
Severity: normal
When attempting to print via CUPS, the job will successfully enter the
queue (the status “Processing” is shown). Then, the job is shown as
“Stopped”; the queue does not progress.
When I then attempt to remove that job – or any job – it simply fails.
The print queue is currently unusable, and its jobs remain there,
stopped.
I am using GNOME 3's printer management.
-- System Information:
Debian Release: 9.0
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cups-daemon depends on:
ii adduser 3.115
ii bc 1.06.95-9+b3
ii dpkg 1.18.23
ii init-system-helpers 1.47
ii libavahi-client3 0.6.32-2
ii libavahi-common3 0.6.32-2
ii libc6 2.24-9
ii libcups2 2.2.2-2
ii libcupsmime1 2.2.2-2
ii libdbus-1-3 1.10.18-1
ii libgssapi-krb5-2 1.15-1
ii libpam0g 1.1.8-3.5
ii libpaper1 1.1.24+nmu5
ii libsystemd0 232-22
ii lsb-base 9.20161125
ii procps 2:3.3.12-3
ii ssl-cert 1.0.38
Versions of packages cups-daemon recommends:
ii avahi-daemon 0.6.32-2
ii colord 1.3.3-2
ii cups-browsed 1.13.4-1
Versions of packages cups-daemon suggests:
ii cups 2.2.2-2
ii cups-bsd 2.2.2-2
ii cups-client 2.2.2-2
ii cups-common 2.2.2-2
ii cups-filters [foomatic-filters] 1.13.4-1
ii cups-ppdc 2.2.1-8
ii cups-server-common 2.2.2-2
ii foomatic-db-compressed-ppds [foomatic-db] 20161201-1
ii ghostscript 9.20~dfsg-3
ii hplip 3.16.11+repack0-2
ii poppler-utils 0.48.0-2
ii printer-driver-cups-pdf [cups-pdf] 2.6.1-22
ii printer-driver-gutenprint 5.2.11-1+b2
ii printer-driver-hpcups 3.16.11+repack0-2
pn smbclient <none>
ii udev 232-22
-- no debconf information
--
\ “We have to go forth and crush every world view that doesn't |
`\ believe in tolerance and free speech.” —David Brin |
_o__) |
Ben Finney <big...@debian.org>
Ben Finney
Apr 18, 2017, 9:00:03 PM4/18/17
to
Control: found -1 cups-daemon/2.2.1-5
Control: found -1 cups-daemon/2.2.1-8
On 19-Apr-2017, Ben Finney wrote:
> When attempting to print via CUPS, the job will successfully enter the
> queue (the status “Processing” is shown). Then, the job is shown as
> “Stopped”; the queue does not progress.
This occurs in both version “2.2.1-8” in current Stretch, and the
version “2.2.2-2” in current Experimental.
--
\ “Are you pondering what I'm pondering?” “I think so, Brain, but |
`\ pants with horizontal stripes make me look chubby.” —_Pinky and |
_o__) The Brain_ |
Ben Finney <big...@debian.org>
Control: found -1 cups-daemon/2.2.1-8
On 19-Apr-2017, Ben Finney wrote:
> When attempting to print via CUPS, the job will successfully enter the
> queue (the status “Processing” is shown). Then, the job is shown as
> “Stopped”; the queue does not progress.
version “2.2.2-2” in current Experimental.
--
\ “Are you pondering what I'm pondering?” “I think so, Brain, but |
`\ pants with horizontal stripes make me look chubby.” —_Pinky and |
_o__) The Brain_ |
Ben Finney <big...@debian.org>
Ben Finney
Apr 18, 2017, 9:00:03 PM4/18/17
to
Control: found -1 cups-daemon/2.2.1-5
Control: found -1 cups-daemon/2.2.1-8
On 19-Apr-2017, Ben Finney wrote:
Control: found -1 cups-daemon/2.2.1-8
On 19-Apr-2017, Ben Finney wrote:
> When attempting to print via CUPS, the job will successfully enter the
> queue (the status “Processing” is shown). Then, the job is shown as
> “Stopped”; the queue does not progress.
> queue (the status “Processing” is shown). Then, the job is shown as
> “Stopped”; the queue does not progress.
Brian Potkin
Apr 19, 2017, 6:00:04 AM4/19/17
to
Thank you for your report, Ben.
On Wed 19 Apr 2017 at 10:30:39 +1000, Ben Finney wrote:
> When attempting to print via CUPS, the job will successfully enter the
> queue (the status “Processing” is shown). Then, the job is shown as
> “Stopped”; the queue does not progress.
>
> When I then attempt to remove that job – or any job – it simply fails.
> The print queue is currently unusable, and its jobs remain there,
> stopped.
>
> I am using GNOME 3's printer management.
The printer make and model, please. Also, the outputs from
lpstat -t
and
lpoptions -p <queue_name>
Regards,
Brian.
On Wed 19 Apr 2017 at 10:30:39 +1000, Ben Finney wrote:
> When attempting to print via CUPS, the job will successfully enter the
> queue (the status “Processing” is shown). Then, the job is shown as
> “Stopped”; the queue does not progress.
>
> When I then attempt to remove that job – or any job – it simply fails.
> The print queue is currently unusable, and its jobs remain there,
> stopped.
>
> I am using GNOME 3's printer management.
lpstat -t
and
lpoptions -p <queue_name>
Regards,
Brian.
Ben Finney
Apr 19, 2017, 7:20:03 AM4/19/17
to
On 19-Apr-2017, Brian Potkin wrote:
> The printer make and model, please.
This occurs with both printers I have available.
> The printer make and model, please.
Samsung SCX-4623F
HP LaserJet Pro MFP-M227fdw
Earlier versions (Debian Stretch, mid-to-late 2016) of CUPS on this
host were working fine with the Samsung printer.
> lpstat -t
> lpoptions -p <queue_name>
=====
$ lpstat -t
scheduler is running
system default destination: SCX-4623-Series
device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
device for PDF: cups-pdf:/
device for SCX-4623-Series: usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
device for XP-310: usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
device for XP-310-Series: usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
HP-LaserJet-MFP-M227-M231 accepting requests since Tue 18 Apr 2017 20:33:31 AEST
PDF accepting requests since Tue 18 Apr 2017 20:22:05 AEST
SCX-4623-Series accepting requests since Wed 19 Apr 2017 21:03:20 AEST
XP-310 accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
XP-310-Series accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
printer HP-LaserJet-MFP-M227-M231 is idle. enabled since Tue 18 Apr 2017 20:33:31 AEST
printer PDF is idle. enabled since Tue 18 Apr 2017 20:22:05 AEST
printer SCX-4623-Series now printing SCX-4623-Series-65. enabled since Wed 19 Apr 2017 21:03:20 AEST
Waiting for printer to become available.
printer XP-310 disabled since Fri 30 Dec 2016 12:00:16 AEDT -
Unplugged or turned off
printer XP-310-Series disabled since Fri 30 Dec 2016 12:00:16 AEDT -
Unplugged or turned off
HP-LaserJet-MFP-M227-M231-64 bignose 1024 Tue 18 Apr 2017 20:33:29 AEST
SCX-4623-Series-65 bignose 1024 Wed 19 Apr 2017 21:03:20 AEST
$ lpoptions -p SCX-4623-Series
copies=1 device-uri=usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1 finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=none printer-info='Samsung SCX-4623 Series' printer-is-accepting-jobs=true printer-is-shared=true printer-location=lantana printer-make-and-model='Samsung SCX-4623f, 2.0.0' printer-state=4 printer-state-change-time=1492599800 printer-state-reasons=none printer-type=143428 printer-uri-supported=ipp://localhost/printers/SCX-4623-Series
$ lpoptions -p HP-LaserJet-MFP-M227-M231
copies=1 device-uri=dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59 finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=1492511611 marker-colors=#000000,none,none,none,none marker-levels=97,-1,-1,-1,100 marker-names='Black\ Cartridge\ HP\ CF230A,,,,Imaging\ Drum\ HP\ CF232A' marker-types=toner,unknown,unknown,unknown,opc number-up=1 printer-commands=none printer-info='HP LaserJet MFP M227fdw (09EB59)' printer-is-accepting-jobs=true printer-is-shared=true printer-location printer-make-and-model='HP LaserJet MFP m129-m134, hpcups 3.16.11' printer-state=3 printer-state-change-time=1492511611 printer-state-reasons=none printer-type=36876 printer-uri-supported=ipp://localhost/printers/HP-LaserJet-MFP-M227-M231
=====
--
\ “In economics, hope and faith coexist with great scientific |
`\ pretension and also a deep desire for respectability.” —John |
_o__) Kenneth Galbraith, 1970-06-07 |
Ben Finney <big...@debian.org>
Brian Potkin
Apr 19, 2017, 9:10:02 AM4/19/17
to
On Wed 19 Apr 2017 at 21:09:52 +1000, Ben Finney wrote:
> On 19-Apr-2017, Brian Potkin wrote:
>
> > The printer make and model, please.
>
> This occurs with both printers I have available.
>
> Samsung SCX-4623F
> HP LaserJet Pro MFP-M227fdw
>
> Earlier versions (Debian Stretch, mid-to-late 2016) of CUPS on this
> host were working fine with the Samsung printer.
>
> > lpstat -t
> > lpoptions -p <queue_name>
>
> =====
> $ lpstat -t
> scheduler is running
> system default destination: SCX-4623-Series
> device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
There is a direct connection to the printer via its Airprint facilty,
> On 19-Apr-2017, Brian Potkin wrote:
>
> > The printer make and model, please.
>
> This occurs with both printers I have available.
>
> Samsung SCX-4623F
> HP LaserJet Pro MFP-M227fdw
>
> Earlier versions (Debian Stretch, mid-to-late 2016) of CUPS on this
> host were working fine with the Samsung printer.
>
> > lpstat -t
> > lpoptions -p <queue_name>
>
> =====
> $ lpstat -t
> scheduler is running
> system default destination: SCX-4623-Series
> device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
No other CUPS server is involved. A job doesn't get as far as using the
device.
> device for PDF: cups-pdf:/
> device for SCX-4623-Series: usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
> device for XP-310: usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
> device for XP-310-Series: usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
> HP-LaserJet-MFP-M227-M231 accepting requests since Tue 18 Apr 2017 20:33:31 AEST
> PDF accepting requests since Tue 18 Apr 2017 20:22:05 AEST
> SCX-4623-Series accepting requests since Wed 19 Apr 2017 21:03:20 AEST
> XP-310 accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
> XP-310-Series accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
> printer HP-LaserJet-MFP-M227-M231 is idle. enabled since Tue 18 Apr 2017 20:33:31 AEST
> printer PDF is idle. enabled since Tue 18 Apr 2017 20:22:05 AEST
> printer SCX-4623-Series now printing SCX-4623-Series-65. enabled since Wed 19 Apr 2017 21:03:20 AEST
> Waiting for printer to become available.
> printer XP-310 disabled since Fri 30 Dec 2016 12:00:16 AEDT -
> Unplugged or turned off
> printer XP-310-Series disabled since Fri 30 Dec 2016 12:00:16 AEDT -
> Unplugged or turned off
> HP-LaserJet-MFP-M227-M231-64 bignose 1024 Tue 18 Apr 2017 20:33:29 AEST
> SCX-4623-Series-65 bignose 1024 Wed 19 Apr 2017 21:03:20 AEST
with 'cancel -a -x'. Check /var/spool/cups before and after the command.
> $ lpoptions -p SCX-4623-Series
> copies=1 device-uri=usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1 finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=none printer-info='Samsung SCX-4623 Series' printer-is-accepting-jobs=true printer-is-shared=true printer-location=lantana printer-make-and-model='Samsung SCX-4623f, 2.0.0' printer-state=4 printer-state-change-time=1492599800 printer-state-reasons=none printer-type=143428 printer-uri-supported=ipp://localhost/printers/SCX-4623-Series
>
> $ lpoptions -p HP-LaserJet-MFP-M227-M231
> copies=1 device-uri=dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59 finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=1492511611 marker-colors=#000000,none,none,none,none marker-levels=97,-1,-1,-1,100 marker-names='Black\ Cartridge\ HP\ CF230A,,,,Imaging\ Drum\ HP\ CF232A' marker-types=toner,unknown,unknown,unknown,opc number-up=1 printer-commands=none printer-info='HP LaserJet MFP M227fdw (09EB59)' printer-is-accepting-jobs=true printer-is-shared=true printer-location printer-make-and-model='HP LaserJet MFP m129-m134, hpcups 3.16.11' printer-state=3 printer-state-change-time=1492511611 printer-state-reasons=none printer-type=36876 printer-uri-supported=ipp://localhost/printers/HP-LaserJet-MFP-M227-M231
lpadmin -p testq -v /home/<user>/testq-out -E -P </etc/cups/ppd/<PPD_for_the_Samsung>
See the Printing section of the wiki on how to enable debug logging.
Print something to the queue and send a compressed error_log here.
Does a file appear in /home/<user>/?
Cheers,
Brian.
Ben Finney
Apr 19, 2017, 4:40:03 PM4/19/17
to
On 19-Apr-2017, Brian Potkin wrote:
> On Wed 19 Apr 2017 at 21:09:52 +1000, Ben Finney wrote:
>
> > =====
> > $ lpstat -t
> > scheduler is running
> > system default destination: SCX-4623-Series
> > device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
>
> There is a direct connection to the printer via its Airprint facilty,
> No other CUPS server is involved. A job doesn't get as far as using the
> device.
How can you tell that a job doesn't get that far?
> On Wed 19 Apr 2017 at 21:09:52 +1000, Ben Finney wrote:
>
> > =====
> > $ lpstat -t
> > scheduler is running
> > system default destination: SCX-4623-Series
> > device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
>
> There is a direct connection to the printer via its Airprint facilty,
> No other CUPS server is involved. A job doesn't get as far as using the
> device.
> > device for PDF: cups-pdf:/
> > device for SCX-4623-Series: usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
>
> A local connection. Looks ok.
> > printer SCX-4623-Series now printing SCX-4623-Series-65. enabled since Wed 19 Apr 2017 21:03:20 AEST
> > Waiting for printer to become available.
>
> This is a stuck job.
> You should be able to cancel the stuck job and clear the last two
> lines with 'cancel -a -x'. Check /var/spool/cups before and after
> the command.
$ sudo ls -l /var/spool/cups/
total 4
drwxrwx--T 2 root lp 4096 Apr 20 06:21 tmp
[… submit a Test Page job using GNOME 3's control center …]
$ sudo ls -l /var/spool/cups/
total 12
-rw------- 1 root lp 970 Apr 20 06:23 c00066
-rw-r----- 1 root lp 234 Apr 20 06:23 d00066-001
drwxrwx--T 2 root lp 4096 Apr 20 06:23 tmp
$ lpstat -t
$ lpstat -t
scheduler is running
system default destination: SCX-4623-Series
[…]
scheduler is running
system default destination: SCX-4623-Series
SCX-4623-Series accepting requests since Thu 20 Apr 2017 06:23:15 AEST
[…]
printer SCX-4623-Series now printing SCX-4623-Series-66. enabled since Thu 20 Apr 2017 06:23:15 AEST
Waiting for printer to become available.
[…]
SCX-4623-Series-66 bignose 1024 Thu 20 Apr 2017 06:23:15 AEST
$ cancel -a -x
$ sudo ls -l /var/spool/cups/
total 8
-rw------- 1 root lp 970 Apr 20 06:23 c00066
drwxrwx--T 2 root lp 4096 Apr 20 06:23 tmp
=====
> Set up this print queue (as root):
>
> lpadmin -p testq -v /home/<user>/testq-out -E -P </etc/cups/ppd/<PPD_for_the_Samsung>
I initially set up this print queue using GNOME 3 control center. I
didn't need to specify any PPD manually.
The printer has been working unchanged for years until early 2017. Are
you saying I need to remove it and start again? I would prefer to
diagnose what's wrong, so that this problem can be fixed for others
too.
--
\ “Courage is resistance to fear, mastery of fear — not absence |
`\ of fear.” —Mark Twain, _Pudd'n'head Wilson_ |
_o__) |
Ben Finney <big...@debian.org>
Brian Potkin
Apr 19, 2017, 6:10:03 PM4/19/17
to
On Thu 20 Apr 2017 at 06:32:08 +1000, Ben Finney wrote:
> On 19-Apr-2017, Brian Potkin wrote:
> > On Wed 19 Apr 2017 at 21:09:52 +1000, Ben Finney wrote:
> >
> > > =====
> > > $ lpstat -t
> > > scheduler is running
> > > system default destination: SCX-4623-Series
> > > device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
> >
> > There is a direct connection to the printer via its Airprint facilty,
> > No other CUPS server is involved. A job doesn't get as far as using the
> > device.
>
> How can you tell that a job doesn't get that far?
It would have printed. You record that it didn't. Assuming the device is
> On 19-Apr-2017, Brian Potkin wrote:
> > On Wed 19 Apr 2017 at 21:09:52 +1000, Ben Finney wrote:
> >
> > > =====
> > > $ lpstat -t
> > > scheduler is running
> > > system default destination: SCX-4623-Series
> > > device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
> >
> > There is a direct connection to the printer via its Airprint facilty,
> > No other CUPS server is involved. A job doesn't get as far as using the
> > device.
>
> How can you tell that a job doesn't get that far?
correct and wireless and printer are working soundly.
> =====
>
> > Set up this print queue (as root):
> >
> > lpadmin -p testq -v /home/<user>/testq-out -E -P </etc/cups/ppd/<PPD_for_the_Samsung>
>
> Hasn't that already been done?
it to "-v file:/home/<user>/testq-out". The idea is to discover whether
the job goes through the filtering system.
> I initially set up this print queue using GNOME 3 control center. I
> didn't need to specify any PPD manually.
>
> The printer has been working unchanged for years until early 2017. Are
> you saying I need to remove it and start again? I would prefer to
> diagnose what's wrong, so that this problem can be fixed for others
> too.
the suggested outlined diagnostic approch.
Regards,
Brian.
Ben Finney
Apr 19, 2017, 7:00:03 PM4/19/17
to
On 19-Apr-2017, Brian Potkin wrote:
> On Thu 20 Apr 2017 at 06:32:08 +1000, Ben Finney wrote:
> > How can you tell that a job doesn't get that far?
>
> It would have printed. You record that it didn't.
Oh, I thought you were seeing something in the output that
> On Thu 20 Apr 2017 at 06:32:08 +1000, Ben Finney wrote:
> > How can you tell that a job doesn't get that far?
>
> It would have printed. You record that it didn't.
independently verified that, so I wanted to know what that information
was :-)
> > > Set up this print queue (as root):
> > >
> > > lpadmin -p testq -v /home/<user>/testq-out -E -P </etc/cups/ppd/<PPD_for_the_Samsung>
>
> discover whether the job goes through the filtering system.
=====
$ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P /etc/cups/ppd/SCX-4623-Series.ppd
lpadmin: File device URIs have been disabled. To enable, see the FileDevice directive in "/etc/cups/cups-files.conf".
$ sudo emacs /etc/cups/cups-files.conf
$ grep FileDevice /etc/cups/cups-files.conf
FileDevice Yes
$ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P /etc/cups/ppd/SCX-4623-Series.ppd
lpadmin: File device URIs have been disabled. To enable, see the FileDevice directive in "/etc/cups/cups-files.conf".
=====
--
\ “Following fashion and the status quo is easy. Thinking about |
`\ your users' lives and creating something practical is much |
_o__) harder.” —Ryan Singer, 2008-07-09 |
Ben Finney <big...@debian.org>
Brian Potkin
Apr 19, 2017, 7:10:03 PM4/19/17
to
On Thu 20 Apr 2017 at 08:46:21 +1000, Ben Finney wrote:
> =====
> $ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P /etc/cups/ppd/SCX-4623-Series.ppd
> lpadmin: File device URIs have been disabled. To enable, see the FileDevice directive in "/etc/cups/cups-files.conf".
>
> $ sudo emacs /etc/cups/cups-files.conf
>
> $ grep FileDevice /etc/cups/cups-files.conf
> FileDevice Yes
>
> $ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P /etc/cups/ppd/SCX-4623-Series.ppd
> lpadmin: File device URIs have been disabled. To enable, see the FileDevice directive in "/etc/cups/cups-files.conf".
> =====
Did you restart cups?
> =====
> $ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P /etc/cups/ppd/SCX-4623-Series.ppd
> lpadmin: File device URIs have been disabled. To enable, see the FileDevice directive in "/etc/cups/cups-files.conf".
>
> $ sudo emacs /etc/cups/cups-files.conf
>
> $ grep FileDevice /etc/cups/cups-files.conf
> FileDevice Yes
>
> $ sudo lpadmin -p testq -v file:/home/bignose/testq-out -E -P /etc/cups/ppd/SCX-4623-Series.ppd
> lpadmin: File device URIs have been disabled. To enable, see the FileDevice directive in "/etc/cups/cups-files.conf".
> =====
systemctl restart cups
Regards,
Brian.
Ben Finney
Apr 19, 2017, 7:40:04 PM4/19/17
to
On 19-Apr-2017, Brian Potkin wrote:
> Set up this print queue (as root):
>
> lpadmin -p testq -v /home/<user>/testq-out -E -P </etc/cups/ppd/<PPD_for_the_Samsung>
I have set that queue up now.
> Set up this print queue (as root):
>
> lpadmin -p testq -v /home/<user>/testq-out -E -P </etc/cups/ppd/<PPD_for_the_Samsung>
The server now stops when I try to print to a queue:
=====
$ sudo systemctl restart cups
$ sudo systemctl status cups
● cups.service - CUPS Scheduler
Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2017-04-20 09:13:47 AEST; 2s ago
Docs: man:cupsd(8)
Main PID: 15217 (cupsd)
Tasks: 1 (limit: 4915)
Memory: 3.9M
CPU: 32ms
CGroup: /system.slice/cups.service
└─15217 /usr/sbin/cupsd -l
Apr 20 09:13:47 lantana systemd[1]: Started CUPS Scheduler.
$ lpstat -t
scheduler is running
system default destination: SCX-4623-Series
device for HP-LaserJet-MFP-M227-M231: dnssd://HP%20LaserJet%20MFP%20M227fdw%20(09EB59)._ipp._tcp.local/?uuid=564e4333-3930-3031-3137-98e7f409eb59
device for PDF: cups-pdf:/
device for SCX-4623-Series: usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
device for testq: /home/bignose/testq-out
device for SCX-4623-Series: usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
device for XP-310: usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
device for XP-310-Series: usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
HP-LaserJet-MFP-M227-M231 accepting requests since Tue 18 Apr 2017 20:33:31 AEST
PDF accepting requests since Tue 18 Apr 2017 20:22:05 AEST
SCX-4623-Series accepting requests since Wed 05 Apr 2017 11:29:50 AEST
device for XP-310-Series: usb://EPSON/XP-310%20Series?serial=533538503030343819&interface=1
HP-LaserJet-MFP-M227-M231 accepting requests since Tue 18 Apr 2017 20:33:31 AEST
PDF accepting requests since Tue 18 Apr 2017 20:22:05 AEST
testq accepting requests since Thu 20 Apr 2017 08:39:26 AEST
XP-310 accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
XP-310-Series accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
printer HP-LaserJet-MFP-M227-M231 is idle. enabled since Tue 18 Apr 2017 20:33:31 AEST
printer PDF is idle. enabled since Tue 18 Apr 2017 20:22:05 AEST
printer SCX-4623-Series is idle. enabled since Wed 05 Apr 2017 11:29:50 AEST
XP-310-Series accepting requests since Fri 30 Dec 2016 12:00:16 AEDT
printer HP-LaserJet-MFP-M227-M231 is idle. enabled since Tue 18 Apr 2017 20:33:31 AEST
printer PDF is idle. enabled since Tue 18 Apr 2017 20:22:05 AEST
printer testq is idle. enabled since Thu 20 Apr 2017 08:39:26 AEST
printer XP-310 disabled since Fri 30 Dec 2016 12:00:16 AEDT -
Unplugged or turned off
printer XP-310-Series disabled since Fri 30 Dec 2016 12:00:16 AEDT -
Unplugged or turned off
$ sudo cupsctl --debug-logging
Unplugged or turned off
printer XP-310-Series disabled since Fri 30 Dec 2016 12:00:16 AEDT -
Unplugged or turned off
$ [… submit a Test Page job to ‘testq’, using GNOME 3 control center …]
$ lpq
lpq: Unable to connect to server.
$ sudo systemctl status cups
● cups.service - CUPS Scheduler
Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2017-04-20 09:14:08 AEST; 20s ago
Docs: man:cupsd(8)
Process: 15217 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
Main PID: 15217 (code=exited, status=1/FAILURE)
CPU: 44ms
Apr 20 09:13:47 lantana systemd[1]: Started CUPS Scheduler.
Apr 20 09:14:08 lantana systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE
Apr 20 09:14:08 lantana systemd[1]: cups.service: Unit entered failed state.
Apr 20 09:14:08 lantana systemd[1]: cups.service: Failed with result 'exit-code'.
$ ls /home/bignose/testq*
ls: cannot access '/home/bignose/testq*': No such file or directory
=====
I am attaching the resulting ‘/var/log/cups/error_log’ to this message.
--
\ “Sometimes I — no, I don't.” —Steven Wright |
`\ |
_o__) |
Ben Finney <big...@debian.org>
Brian Potkin
Apr 20, 2017, 4:20:02 AM4/20/17
to
On Thu 20 Apr 2017 at 09:19:49 +1000, Ben Finney wrote:
> $ sudo systemctl status cups
> ● cups.service - CUPS Scheduler
> Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
> Active: failed (Result: exit-code) since Thu 2017-04-20 09:14:08 AEST; 20s ago
> Docs: man:cupsd(8)
> Process: 15217 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
> Main PID: 15217 (code=exited, status=1/FAILURE)
> CPU: 44ms
>
> Apr 20 09:13:47 lantana systemd[1]: Started CUPS Scheduler.
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Unit entered failed state.
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Failed with result 'exit-code'.
>
> $ ls /home/bignose/testq*
> ls: cannot access '/home/bignose/testq*': No such file or directory
>
> =====
>
> I am attaching the resulting ‘/var/log/cups/error_log’ to this message.
Thank you for this and all the other detail.
> $ sudo systemctl status cups
> ● cups.service - CUPS Scheduler
> Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
> Active: failed (Result: exit-code) since Thu 2017-04-20 09:14:08 AEST; 20s ago
> Docs: man:cupsd(8)
> Process: 15217 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
> Main PID: 15217 (code=exited, status=1/FAILURE)
> CPU: 44ms
>
> Apr 20 09:13:47 lantana systemd[1]: Started CUPS Scheduler.
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Unit entered failed state.
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Failed with result 'exit-code'.
>
> $ ls /home/bignose/testq*
> ls: cannot access '/home/bignose/testq*': No such file or directory
>
> =====
>
> I am attaching the resulting ‘/var/log/cups/error_log’ to this message.
> I [20/Apr/2017:09:14:08 +1000] [Client 12] Installing config file "/etc/cups/cupsd.conf"...
> D [20/Apr/2017:09:14:08 +1000] [Client 12] cupsdSendHeader: code=201, type="(null)", auth_type=0
> D [20/Apr/2017:09:14:08 +1000] cupsdSetBusyState: newbusy="Dirty files", busy="Active clients and dirty files"
> D [20/Apr/2017:09:14:08 +1000] [Client 12] Closing connection.
> D [20/Apr/2017:09:14:08 +1000] cupsdSetBusyState: newbusy="Dirty files", busy="Dirty files"
> E [20/Apr/2017:09:14:08 +1000] Scheduler shutting down due to program error.
The scheduler crashes. The job gets nowhere near the filtering system.
The symptoms you have described in your first mail could have been
caused by a fault there or (unlikely because the two printers are
connected differently) a backend. This rules those possibilities out.
This is a relatively recent change in behaviour. Could it be CUPS issue
#4915?
https://github.com/apple/cups/issues/4915
Two things to try:
1. Do 'cupsctl debuglevel=warn' and 'systemctl status cups'. cups crashes
for me on the first command.
2. Upgrade experimental to the present cups 2.2.3-1. The changelog has
* Cherry-pick upstream fix for regression in job file preservation
Set up testq again and test for a file in $HOME. Do some printing to
both printers.
Thanks,
--
Brian.
Ben Finney
Apr 20, 2017, 7:20:03 AM4/20/17
to
On 20-Apr-2017, Brian Potkin wrote:
> 1. Do 'cupsctl debuglevel=warn' and 'systemctl status cups'. cups crashes
> for me on the first command.
> 1. Do 'cupsctl debuglevel=warn' and 'systemctl status cups'. cups crashes
> for me on the first command.
=====
$ sudo systemctl restart cups
$ sudo systemctl restart cups
$ sudo systemctl status cups
● cups.service - CUPS Scheduler
Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2017-04-20 21:00:04 AEST; 1s ago
● cups.service - CUPS Scheduler
Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
Docs: man:cupsd(8)
Main PID: 8587 (cupsd)
Tasks: 4 (limit: 4915)
Memory: 6.4M
CPU: 311ms
CGroup: /system.slice/cups.service
├─8587 /usr/sbin/cupsd -l
├─8594 SCX-4623-Series 68 bignose Test page 1 job-uuid=urn:uuid:8b94617c-da70-3de2-40ae-62d8e2feba78 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1492684769 time-at-proces
└─8595 usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1 68 bignose Test page 1 job-uuid=urn:uuid:8b94617c-da70-3de2-40ae-62d8e2feba78 job-originating-host-name=localhost date-time-at-creation= date-time-at-pro
Apr 20 21:00:04 lantana systemd[1]: Started CUPS Scheduler.
$ sudo cupsctl debuglevel=warn
$ sudo systemctl status cups
● cups.service - CUPS Scheduler
Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
Docs: man:cupsd(8)
Process: 8587 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
Main PID: 8587 (code=exited, status=1/FAILURE)
CPU: 324ms
Apr 20 21:00:04 lantana systemd[1]: Started CUPS Scheduler.
Apr 20 21:00:13 lantana systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE
Apr 20 21:00:13 lantana systemd[1]: cups.service: Unit entered failed state.
Apr 20 21:00:13 lantana systemd[1]: cups.service: Failed with result 'exit-code'.
=====
--
\ “Human reason is snatching everything to itself, leaving |
`\ nothing for faith.” —Bernard of Clairvaux, 1090–1153 CE |
_o__) |
Ben Finney <big...@debian.org>
Brian Potkin
Apr 20, 2017, 10:00:03 AM4/20/17
to
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.
On Thu 20 Apr 2017 at 21:03:08 +1000, Ben Finney wrote:
> Well, now I have slightly different behaviour without changing CUPS
> version. I don't know what could explain the difference, but I see
> this behaviour now:
Isn't life interesting? :)
> * Restart the ‘cups’ service.
>
> * Use gnome-control-center to submit a test page job to ‘testq’.
> * The job appears in the ‘testq’ queue.
> * The job is shown as “Processing”.
> * The ‘~/testq-out’ file appears.
> * The job disappears from the ‘testq’ queue.
A log should be very similar to the one for the Samsung SCX-4623 Series
queue as regards the filters used. I'd advise printing to testq quite a
few times to ensure it continues to work.
> * Use gnome-control center to submit a test page job to ‘Samsung
> SCX-4623 Series’ queue.
> * The job appears in the ‘testq’ queue.
> * The job is shown as “Processing”.
> * The printer remains inactive.
>
> So the ‘testq’ queue works now, while the ‘Samsung SCX-4623 Series’
> queue exhibits the same failure.
>
> I have attached the corresponding ‘/var/log/error_log’.
Job 68 is the one of interest.
D [20/Apr/2017:20:51:03 +1000] [Job 68] argv[0]="SCX-4623-Series"
The queue name.
D [20/Apr/2017:20:51:03 +1000] [Job 68] argv[3]="Test page"
The job name.
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/bannertopdf (PID 20520)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/pdftopdf (PID 20521)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/gstoraster (PID 20522)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/rastertoqpdl (PID 20523)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started backend /usr/lib/cups/backend/usb (PID 20524)
The filters and backend used.
D [20/Apr/2017:20:51:03 +1000] [Job 68] SpliX SpliX filter V. 2.0.0 by Aurélien Croc (AP²C)
Confirmation of the printer driver used.
D [20/Apr/2017:20:51:03 +1000] [Job 68] Printing on printer with URI: usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
D [20/Apr/2017:20:51:03 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:03 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:03 +1000] [Job 68] Set job-printer-state-message to "Waiting for printer to become available.", current level=INFO
Oh!
D [20/Apr/2017:20:51:03 +1000] [Job 68] PID 20520 (/usr/lib/cups/filter/bannertopdf) exited with no errors.
D [20/Apr/2017:20:51:03 +1000] [Job 68] PID 20521 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
Fine.
D [20/Apr/2017:20:51:03 +1000] [Job 68] Start rendering...
D [20/Apr/2017:20:51:03 +1000] [Job 68] Set job-printer-state-message to "Start rendering...", current level=INFO
D [20/Apr/2017:20:51:03 +1000] [Job 68] Processing page 1...
We are off to the races!
D [20/Apr/2017:20:51:04 +1000] [Job 68] PID 20522 (/usr/lib/cups/filter/gstoraster) exited with no errors.
That's good. But where is rastertoqpdl exiting? Job 70 uses it.
D [20/Apr/2017:20:51:04 +1000] [Job 68] SpliX Page 1 has been compressed and is ready for rendering
D [20/Apr/2017:20:51:04 +1000] [Job 68] SpliX Compression thread: work done. See ya
D [20/Apr/2017:20:51:08 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:08 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:08 +1000] [Job 68] Set job-printer-state-message to "Waiting for printer to become available.", current level=INFO
D [20/Apr/2017:20:51:13 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:13 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:18 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:18 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:23 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:23 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:28 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:28 +1000] [Job 68] Waiting for printer to become available.
Very worrying.
D [20/Apr/2017:20:51:33 +1000] [Job 68] Unloading...
CUPS gives up. A USB problem? A Printer problem?
More testing, I'm afraid.
Take the file in your $HOME produced by testq. The file utility should
identify it as "HP Printer Job Language data". Send it directly to the
printer with
cat <printer-ready_file> > /dev/usb/lp0
Does it print?
Also send the same file with
lp -d <SCX-4623 Series queue> -o raw <printer-ready_file>
Does it print?
Thanks,
--
Brian.
debian-printing and I get them by SMTP. It is better to compress
log files, otherwise I have to go looking for the CC.
On Thu 20 Apr 2017 at 21:03:08 +1000, Ben Finney wrote:
> Well, now I have slightly different behaviour without changing CUPS
> version. I don't know what could explain the difference, but I see
> this behaviour now:
Isn't life interesting? :)
> * Restart the ‘cups’ service.
>
> * Use gnome-control-center to submit a test page job to ‘testq’.
> * The job appears in the ‘testq’ queue.
> * The job is shown as “Processing”.
> * The ‘~/testq-out’ file appears.
> * The job disappears from the ‘testq’ queue.
A log should be very similar to the one for the Samsung SCX-4623 Series
queue as regards the filters used. I'd advise printing to testq quite a
few times to ensure it continues to work.
> * Use gnome-control center to submit a test page job to ‘Samsung
> SCX-4623 Series’ queue.
> * The job appears in the ‘testq’ queue.
> * The job is shown as “Processing”.
> * The printer remains inactive.
>
> So the ‘testq’ queue works now, while the ‘Samsung SCX-4623 Series’
> queue exhibits the same failure.
>
> I have attached the corresponding ‘/var/log/error_log’.
Job 68 is the one of interest.
D [20/Apr/2017:20:51:03 +1000] [Job 68] argv[0]="SCX-4623-Series"
The queue name.
D [20/Apr/2017:20:51:03 +1000] [Job 68] argv[3]="Test page"
The job name.
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/bannertopdf (PID 20520)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/pdftopdf (PID 20521)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/gstoraster (PID 20522)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started filter /usr/lib/cups/filter/rastertoqpdl (PID 20523)
I [20/Apr/2017:20:51:03 +1000] [Job 68] Started backend /usr/lib/cups/backend/usb (PID 20524)
The filters and backend used.
D [20/Apr/2017:20:51:03 +1000] [Job 68] SpliX SpliX filter V. 2.0.0 by Aurélien Croc (AP²C)
Confirmation of the printer driver used.
D [20/Apr/2017:20:51:03 +1000] [Job 68] Printing on printer with URI: usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N&interface=1
D [20/Apr/2017:20:51:03 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:03 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:03 +1000] [Job 68] Set job-printer-state-message to "Waiting for printer to become available.", current level=INFO
Oh!
D [20/Apr/2017:20:51:03 +1000] [Job 68] PID 20520 (/usr/lib/cups/filter/bannertopdf) exited with no errors.
D [20/Apr/2017:20:51:03 +1000] [Job 68] PID 20521 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
Fine.
D [20/Apr/2017:20:51:03 +1000] [Job 68] Start rendering...
D [20/Apr/2017:20:51:03 +1000] [Job 68] Set job-printer-state-message to "Start rendering...", current level=INFO
D [20/Apr/2017:20:51:03 +1000] [Job 68] Processing page 1...
We are off to the races!
D [20/Apr/2017:20:51:04 +1000] [Job 68] PID 20522 (/usr/lib/cups/filter/gstoraster) exited with no errors.
That's good. But where is rastertoqpdl exiting? Job 70 uses it.
D [20/Apr/2017:20:51:04 +1000] [Job 68] SpliX Page 1 has been compressed and is ready for rendering
D [20/Apr/2017:20:51:04 +1000] [Job 68] SpliX Compression thread: work done. See ya
D [20/Apr/2017:20:51:08 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:08 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:08 +1000] [Job 68] Set job-printer-state-message to "Waiting for printer to become available.", current level=INFO
D [20/Apr/2017:20:51:13 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:13 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:18 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:18 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:23 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:23 +1000] [Job 68] Waiting for printer to become available.
D [20/Apr/2017:20:51:28 +1000] [Job 68] libusb_get_device_list=9
D [20/Apr/2017:20:51:28 +1000] [Job 68] Waiting for printer to become available.
Very worrying.
D [20/Apr/2017:20:51:33 +1000] [Job 68] Unloading...
CUPS gives up. A USB problem? A Printer problem?
More testing, I'm afraid.
Take the file in your $HOME produced by testq. The file utility should
identify it as "HP Printer Job Language data". Send it directly to the
printer with
cat <printer-ready_file> > /dev/usb/lp0
Does it print?
Also send the same file with
lp -d <SCX-4623 Series queue> -o raw <printer-ready_file>
Does it print?
Thanks,
--
Brian.
Brian Potkin
Apr 20, 2017, 10:00:03 AM4/20/17
to
--
Brian.
Brian Potkin
Apr 20, 2017, 6:10:02 PM4/20/17
to
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!
> /home/bignose/testq-out: HP Printer Job Language data
>
> $ 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>
>
> 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.
> 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.
>
>
> 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 :-)
> > More testing, I'm afraid.
>
>
> > 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
> > Take the file in your $HOME produced by testq. The file utility should
> > identify it as "HP Printer Job Language data".
>
> /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:
> > Send it directly to the printer with
> >
> > cat <printer-ready_file> > /dev/usb/lp0
>
>
> $ 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'
> $ sudo systemctl restart cups
>
> 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.
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.
Ben Finney
Apr 21, 2017, 8:40:04 AM4/21/17
to
On 20-Apr-2017, Brian Potkin wrote:
> On Fri 21 Apr 2017 at 06:05:02 +1000, Ben Finney wrote:
> > On 20-Apr-2017, Brian Potkin wrote:
> > > 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
There was *no directory* named ‘/dev/usb/’.
> On Fri 21 Apr 2017 at 06:05:02 +1000, Ben Finney wrote:
> > On 20-Apr-2017, Brian Potkin wrote:
> > > 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
That turned out to be key to me figuring out this mystery: The USB
hub's power had come unplugged. It was responding to some devices, but
not all.
Now that I have the USB hub properly plugged in:
* The ‘/dev/usb/lp0’ node appears.
* The ‘lsusb’ output shows an entry for the USB-connected printer.
* The ‘cat ~bignose/testq-out > /dev/usb/lp0’ command prints the file.
That leaves the problem of failing to print to the HP printer
connected via 802.11, which would not be affected by the USB hub. I
will try again later to diagnose that one.
--
\ “Hanging one scoundrel, it appears, does not deter the next. |
`\ Well, what of it? The first one is at least disposed of.” |
_o__) —Henry L. Mencken |
Ben Finney <big...@debian.org>
Brian Potkin
Apr 21, 2017, 10:00:04 AM4/21/17
to
On Fri 21 Apr 2017 at 22:15:08 +1000, Ben Finney wrote:
> On 20-Apr-2017, Brian Potkin wrote:
> > On Fri 21 Apr 2017 at 06:05:02 +1000, Ben Finney wrote:
> > > On 20-Apr-2017, Brian Potkin wrote:
> > > > 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
>
> There was *no directory* named ‘/dev/usb/’.
>
> That turned out to be key to me figuring out this mystery: The USB
> hub's power had come unplugged. It was responding to some devices, but
> not all.
Great.
> On 20-Apr-2017, Brian Potkin wrote:
> > On Fri 21 Apr 2017 at 06:05:02 +1000, Ben Finney wrote:
> > > On 20-Apr-2017, Brian Potkin wrote:
> > > > 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
>
> There was *no directory* named ‘/dev/usb/’.
>
> That turned out to be key to me figuring out this mystery: The USB
> hub's power had come unplugged. It was responding to some devices, but
> not all.
I bought a packet yesterday containing what I thought was an SD card and
a micro SD card. 'lsblk' showed nothing when I plugged the "SD card"
into slots on the readers I have. Before returning it to the shop I
purchased it from I consulted a friend. He pointed out the word "adapter"
on the "SD card" and asked why I hadn't plugged the micro SD card into
it!
> Now that I have the USB hub properly plugged in:
>
> * The ‘/dev/usb/lp0’ node appears.
> * The ‘lsusb’ output shows an entry for the USB-connected printer.
> * The ‘cat ~bignose/testq-out > /dev/usb/lp0’ command prints the file.
> That leaves the problem of failing to print to the HP printer
> connected via 802.11, which would not be affected by the USB hub. I
> will try again later to diagnose that one.
Regards,
Brian.
Brian Potkin
Apr 29, 2017, 8:20:02 AM4/29/17
to
On Fri 21 Apr 2017 at 22:15:08 +1000, Ben Finney wrote:
> That leaves the problem of failing to print to the HP printer
> connected via 802.11, which would not be affected by the USB hub. I
> will try again later to diagnose that one.
Any news on this?
> That leaves the problem of failing to print to the HP printer
> connected via 802.11, which would not be affected by the USB hub. I
> will try again later to diagnose that one.
Cheers,
Brian.
Brian Potkin
Apr 29, 2017, 9:10:03 AM4/29/17
to
On Thu 20 Apr 2017 at 14:50:55 +0100, Brian Potkin wrote:
> > $ sudo cupsctl debuglevel=warn
The line "debuglevel=warn" will be in your cupsd.conf. You can edit the
file to remove it.
> > $ sudo systemctl status cups
> > ● cups.service - CUPS Scheduler
> > Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
> > Active: failed (Result: exit-code) since Thu 2017-04-20 21:00:13 AEST; 1s ago
> > Docs: man:cupsd(8)
> > Process: 8587 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
> > Main PID: 8587 (code=exited, status=1/FAILURE)
> > CPU: 324ms
> >
> > Apr 20 21:00:04 lantana systemd[1]: Started CUPS Scheduler.
> > Apr 20 21:00:13 lantana systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE
> > Apr 20 21:00:13 lantana systemd[1]: cups.service: Unit entered failed state.
> > Apr 20 21:00:13 lantana systemd[1]: cups.service: Failed with result 'exit-code'.
>
> We get the same outcome. This looks like a different issue from yours.
#861470
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861470
--
Brian.
> > $ sudo cupsctl debuglevel=warn
The line "debuglevel=warn" will be in your cupsd.conf. You can edit the
file to remove it.
> > $ sudo systemctl status cups
> > ● cups.service - CUPS Scheduler
> > Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
> > Active: failed (Result: exit-code) since Thu 2017-04-20 21:00:13 AEST; 1s ago
> > Docs: man:cupsd(8)
> > Process: 8587 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
> > Main PID: 8587 (code=exited, status=1/FAILURE)
> > CPU: 324ms
> >
> > Apr 20 21:00:04 lantana systemd[1]: Started CUPS Scheduler.
> > Apr 20 21:00:13 lantana systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE
> > Apr 20 21:00:13 lantana systemd[1]: cups.service: Unit entered failed state.
> > Apr 20 21:00:13 lantana systemd[1]: cups.service: Failed with result 'exit-code'.
>
> We get the same outcome. This looks like a different issue from yours.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861470
--
Brian.
0 new messages