Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-29 Thread Brian Potkin
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.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-29 Thread Brian Potkin
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?

Cheers,

Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-21 Thread Brian Potkin
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  > /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.

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.

All systems go, then.

> 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.

Consider using the output of 'avahi-browse -art' as a diagnostc.

Regards,

Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-21 Thread Ben Finney
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  > /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.

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 


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-20 Thread Brian Potkin
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  > /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  -o raw 
> 
> =
> $ 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  > /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.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-20 Thread Ben Finney
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  > /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

> Also send the same file with
> 
>   lp -d  -o raw 

=
$ 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.

-- 
 \   “Anger makes dull men witty, but it keeps them poor.” |
  `\  —Elizabeth Tudor |
_o__)  |
Ben Finney 


error_log.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-20 Thread Brian Potkin
On Thu 20 Apr 2017 at 21:04:28 +1000, Ben Finney wrote:

> On 20-Apr-2017, Brian Potkin wrote:
> 
> > 1. Do 'cupsctl debuglevel=warn' and 'systemctl status cups'. cups crashes
> >for me on the first command.
> 
> =
> $ 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
>  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=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)
>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.

-- 
Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-20 Thread Brian Potkin
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=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  > /dev/usb/lp0

Does it print?

Also send the same file with

  lp -d  -o raw 

Does it print?

Thanks,

-- 
Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-20 Thread Ben Finney
On 20-Apr-2017, Brian Potkin wrote:

> 1. Do 'cupsctl debuglevel=warn' and 'systemctl status cups'. cups crashes
>for me on the first command.

=
$ 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
 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=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)
   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'.
=

-- 
 \“Human reason is snatching everything to itself, leaving |
  `\   nothing for faith.” —Bernard of Clairvaux, 1090–1153 CE |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-20 Thread Brian Potkin
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.

> 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.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Ben Finney
On 19-Apr-2017, Brian Potkin wrote:

> Set up this print queue (as root):
> 
>  lpadmin -p testq -v /home//testq-out -E -P 
> 

I have set that queue up now.

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=1
device for testq: /home/bignose/testq-out
device for XP-310: 
usb://EPSON/XP-310%20Series?serial=533538503030343819=1
device for XP-310-Series: 
usb://EPSON/XP-310%20Series?serial=533538503030343819=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
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
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

$ [… 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 
I [20/Apr/2017:09:13:47 +1000] Listening to [v1.::1]:631 (IPv6)
I [20/Apr/2017:09:13:47 +1000] Listening to 127.0.0.1:631 (IPv4)
I [20/Apr/2017:09:13:47 +1000] Listening to /var/run/cups/cups.sock (Domain)
I [20/Apr/2017:09:13:47 +1000] Remote access is disabled.
D [20/Apr/2017:09:13:47 +1000] Added auto ServerAlias lantana
I [20/Apr/2017:09:13:47 +1000] Loaded configuration file "/etc/cups/cupsd.conf"
D [20/Apr/2017:09:13:47 +1000] Using keychain "/etc/cups/ssl" for server name 
"lantana".
I [20/Apr/2017:09:13:47 +1000] Using default TempDir of /var/spool/cups/tmp...
I [20/Apr/2017:09:13:47 +1000] Configured for up to 100 clients.
I [20/Apr/2017:09:13:47 +1000] Allowing up to 100 client connections per host.
I [20/Apr/2017:09:13:47 +1000] Using policy "default" as the default.
I [20/Apr/2017:09:13:47 +1000] Full reload is required.
I [20/Apr/2017:09:13:47 +1000] Loaded MIME database from "/usr/share/cups/mime" 
and "/etc/cups": 50 types, 86 filters...
D [20/Apr/2017:09:13:47 +1000] Loading printer HP-LaserJet-MFP-M227-M231...
D [20/Apr/2017:09:13:47 +1000] load_ppd: Loading 
/var/cache/cups/HP-LaserJet-MFP-M227-M231.data...
D [20/Apr/2017:09:13:47 +1000] 
cupsdRegisterPrinter(p=0x55c12f42e4b0(HP-LaserJet-MFP-M227-M231))
D [20/Apr/2017:09:13:47 +1000] load_ppd: Loading 
/var/cache/cups/HP-LaserJet-MFP-M227-M231.data...
D [20/Apr/2017:09:13:47 +1000] 
cupsdRegisterPrinter(p=0x55c12f42e4b0(HP-LaserJet-MFP-M227-M231))
D [20/Apr/2017:09:13:47 +1000] Loading printer PDF...
D [20/Apr/2017:09:13:47 +1000] load_ppd: Loading 

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Brian Potkin
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?

systemctl restart cups

Regards,

Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Ben Finney
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
independently verified that, so I wanted to know what that information
was :-)

> > > Set up this print queue (as root):
> > >
> > >  lpadmin -p testq -v /home//testq-out -E -P 
> > > 
>
> […] change it to "-v file:/home//testq-out". The idea is to
> 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 


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Brian Potkin
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
correct and wireless and printer are working soundly.

> > > device for PDF: cups-pdf:/
> > > device for SCX-4623-Series: 
> > > usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N=1
> > 
> > A local connection. Looks ok.
> 
> This is the printer queue which worked fine until early 2017.
> 
> > > 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.
> 
> Every job that I submit now gets stuck like this.
> 
> > 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
> […]
> 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
> 

The d file has been removed from the queue.

> =
> 
> > Set up this print queue (as root):
> > 
> >  lpadmin -p testq -v /home//testq-out -E -P 
> > 
> 
> Hasn't that already been done?

No. Note the different device-uri (-v). However, it is incorrect; change
it to "-v file:/home//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.

I haven't said anything about removing your present queues as part of
the suggested outlined diagnostic approch.

Regards,

Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Ben Finney
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?

> > device for PDF: cups-pdf:/
> > device for SCX-4623-Series: 
> > usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N=1
> 
> A local connection. Looks ok.

This is the printer queue which worked fine until early 2017.

> > 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.

Every job that I submit now gets stuck like this.

> 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
[…]
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//testq-out -E -P 
> 

Hasn't that already been done?

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 


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Brian Potkin
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 
> 
> =
> $ 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=1

A local connection. Looks ok.

> device for XP-310: 
> usb://EPSON/XP-310%20Series?serial=533538503030343819=1
> device for XP-310-Series: 
> usb://EPSON/XP-310%20Series?serial=533538503030343819=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.

This is a stuck job.

> 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

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.
 
> $ lpoptions -p SCX-4623-Series
> copies=1 
> device-uri=usb://Samsung/SCX-4623%20Series?serial=Z2WUBFFZ300396N=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=#00,none,none,none,none marker-levels=97,-1,-1,-1,100 
> marker-names='Black\ Cartridge\ HP\ CF230AImaging\ 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

Set up this print queue (as root):

 lpadmin -p testq -v /home//testq-out -E -P 


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//?

Cheers,

Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Ben Finney
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 

=
$ 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=1
device for XP-310: 
usb://EPSON/XP-310%20Series?serial=533538503030343819=1
device for XP-310-Series: 
usb://EPSON/XP-310%20Series?serial=533538503030343819=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=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=#00,none,none,none,none marker-levels=97,-1,-1,-1,100 
marker-names='Black\ Cartridge\ HP\ CF230AImaging\ 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 


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-19 Thread Brian Potkin
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 

Regards,

Brian.



Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-18 Thread Ben Finney
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 


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-18 Thread Ben Finney
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 


signature.asc
Description: PGP signature


Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed

2017-04-18 Thread Ben Finney
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  libc62.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  libpaper11.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  colord1.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-client2.2.2-2
ii  cups-common2.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  ghostscript9.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  
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 


signature.asc
Description: PGP signature