ipp jobs not purged; purging causes 100% cpu usage

[trshemanske]

I am running a current version of dapper, and have two printers configured via gnome-cups-manager. The local printer HP PSC2175 is connected via USB, and functions correctly. I also have a network printer (HP Laserjet 1200) configured via ipp.

The jobs to the ipp printer print correctly, but cups-gnome-manager continues to report that the job is still printing. Upon reboot the same job will reprint. If you manually cancel the job via the gnome-cups-manager or via lprm, "top" reports that ipp is consuming 100% cpu, and the ipp job must be manually canceled.

This occurs on two separate dapper installations both using cups as a server not client.

[Martin Pitt (pitti)]

Can you please attach /var/log/cups/error_log after trying to print something, and also paste the output of

  lpinfo

and

  lpinfo -v

here? Thank you!

[trshemanske (thomas-r-shemanske)]

Martin Pitt wrote:
> Can you please attach /var/log/cups/error_log after trying to print
> something, and also paste the output of
>

/var/log/cups/access_log:
localhost - - [15/May/2006:06:20:20 -0400] "POST / HTTP/1.1" 200 352
CUPS-Get-Classes successful-ok
localhost - - [15/May/2006:06:20:22 -0400] "POST / HTTP/1.1" 200 352
CUPS-Get-Classes successful-ok
localhost - - [15/May/2006:06:20:22 -0400] "POST / HTTP/1.1" 200 352
CUPS-Get-Classes successful-ok
localhost - - [15/May/2006:06:20:24 -0400] "POST / HTTP/1.1" 200 352
CUPS-Get-Classes successful-ok
localhost - - [15/May/2006:06:20:26 -0400] "POST / HTTP/1.1" 200 352
CUPS-Get-Classes successful-ok
localhost - - [15/May/2006:06:20:26 -0400] "POST
/printers/LaserJet-1200-Postscript-(recommended) HTTP/1.1" 200
64302 - successful-ok
localhost - - [15/May/2006:06:21:53 -0400] "POST / HTTP/1.1" 200 158
Get-Jobs successful-ok
localhost - - [15/May/2006:06:21:56 -0400] "POST / HTTP/1.1" 200 158
Get-Jobs successful-ok
localhost - - [15/May/2006:06:21:56 -0400] "POST /jobs HTTP/1.1" 200 141
Cancel-Job successful-ok
localhost - - [15/May/2006:06:21:56 -0400] "POST / HTTP/1.1" 200 158
Get-Jobs successful-ok

/var/log/cups/error_log:
E [15/May/2006:06:26:20 -0400] PID 16787 (/usr/lib/cups/backend/ipp)
stopped with status 1!

/var/log/cups/page_log:
LaserJet-1200-Postscript-(recommended) linda 289 [15/May/2006:06:20:28
-0400] 1 1 - localhost

> lpinfo

*** blank***

>
> and
>
> lpinfo -v

linda@shemanske:~$ lpinfo -v
network socket
network beh
network bluetooth
direct usb://HP/PSC%202170%20Series?serial=MY366C90YY73
direct hp:/usb/PSC_2170_Series?serial=MY366C90YY73
network http
network ipp
network lpd
direct parallel:/dev/lp0
direct canon:/dev/lp0
direct epson:/dev/lp0
direct ptal
network smb

>
> here? Thank you!
>
> ** Changed in: gnome-cups-manager (Ubuntu)
> Sourcepackagename: gnome-cups-manager => cupsys
> Status: Unconfirmed => Needs Info
>

--
  .''`. Thomas R. Shemanske, Professor and Chair
: :' : (mailing, office and internet information below)
`. `'`
   `- Debian - when you have better things to do than fix a system ...

(Mailing Address) (Office/Internet Information)
Department of Mathematics 203 Choate House
6188 Bradley Hall <email address hidden>
Dartmouth College http://www.math.dartmouth.edu/~trs/
Hanover, NH 03755-3551 (603) 646 - 3179

Directions: http://www.math.dartmouth.edu/~trs/choatehouse.html
Office hours: http://www.math.dartmouth.edu/~trs/frontmatter/office.html

[trshemanske (thomas-r-shemanske)]

Earlier comments were entered on this bug via gnome-cups-manager

New input:
I tried this laptop on a separate network and ipp printers successfully reported completed jobs.

This suggests something intrinsic to my home LAN and print server. In particular that the print server is not reporting completion of the print job. However this is in contrast to the behavior under the previous version (breezy) of cups.

I tried with http with exactly the same result as ipp

Switching to lpd://***** works just fine, so there is some subtle backend bug in the ipp, http protocols.

That's about all I can say

[Ante Karamatić (ivoks)]

Please set LogLevel to debug2, restart CUPS, try printing again and attach error_log. Please, don't paste it in message.

[trshemanske (thomas-r-shemanske)]

Attached is the requested cups error log the log level set to debug2

[Ante Karamatić (ivoks)]

Could you please try packages at http://www.grad.hr/~ivoks/ubuntu/cups and report changes?

[trshemanske (thomas-r-shemanske)]

Ante Karamatić wrote:
> Could you please try packages at http://www.grad.hr/~ivoks/ubuntu/cups
> and report changes?
>

The behavior is unchanged in every respect

TRS

root@shemanskeLAC:/home/trs/ubuntu# dpkg -l | grep cups
ii bluez-cups 2.24-0ubuntu6
          Bluetooth printer driver for CUPS
ii cupsys 1.2.1-0ivoks0.1
          Common UNIX Printing System(tm) - server
ii cupsys-bsd 1.2.1-0ivoks0.1
          Common UNIX Printing System(tm) - BSD comman
ii cupsys-client 1.2.1-0ivoks0.1
          Common UNIX Printing System(tm) - client pro
ii cupsys-driver-gimpprint 5.0.0~rc3-0ivoks0.1
          printer drivers for CUPS
ii cupsys-driver-gutenprint 5.0.0~rc3-0ivoks0.1
          printer drivers for CUPS
ii gnome-cups-manager 0.31-1.1ubuntu13
          CUPS printer admin tool for GNOME
ii libcupsimage2 1.2.1-0ivoks0.1
          Common UNIX Printing System(tm) - image libs
ii libcupsys2 1.2.1-0ivoks0.1
          Common UNIX Printing System(tm) - libs
ii libcupsys2-dev 1.2.1-0ivoks0.1
          Common UNIX Printing System(tm) - developmen
ii libcupsys2-gnutls10 1.2.1-0ivoks0.1
          Common UNIX Printing System(tm) - dummy libs
ii libgnomecups1.0-1 0.2.2-1ubuntu5
          GNOME library for CUPS interaction
rc libgnomecupsui1.0-1 0.31-0ubuntu3
          UI extensions to libgnomecups
ii libgnomecupsui1.0-1c2a 0.31-1.1ubuntu13
          UI extensions to libgnomecups

root@shemanskeLAC:/home/trs/ubuntu# /etc/init.d/cupsys restart
  * Restarting Common Unix Printing System: cupsd
                                        [ ok ]

root@shemanskeLAC:/home/trs/ubuntu# killall ipp

--
  .''`. Thomas R. Shemanske, Professor and Chair
: :' : (mailing, office and internet information below)
`. `'`
   `- Debian - when you have better things to do than fix a system ...

(Mailing Address) (Office/Internet Information)
Department of Mathematics 203 Choate House
6188 Bradley Hall <email address hidden>
Dartmouth College http://www.math.dartmouth.edu/~trs/
Hanover, NH 03755-3551 (603) 646 - 3179

Directions: http://www.math.dartmouth.edu/~trs/choatehouse.html
Office hours: http://www.math.dartmouth.edu/~trs/frontmatter/office.html

[Ante Karamatić (ivoks)]

Please attach you /etc/cups/cupsd.conf and both files in /etc/cups/cups.d/.

[trshemanske (thomas-r-shemanske)]

Ante Karamatić wrote:
> Please attach you /etc/cups/cupsd.conf and both files in
> /etc/cups/cups.d/.
>

Files attached

I tried this with cupsys cupsys-client and cupsys-bsd at versions

1.2.1-0ivoks0.1 and 1.2.1-0ivoks0.3

with the same results. I could attach the error log if you think it
would be useful

TRS

--
  .''`. Thomas R. Shemanske, Professor and Chair
: :' : (mailing, office and internet information below)
`. `'`
   `- Debian - when you have better things to do than fix a system ...

(Mailing Address) (Office/Internet Information)
Department of Mathematics 203 Choate House
6188 Bradley Hall <email address hidden>
Dartmouth College http://www.math.dartmouth.edu/~trs/
Hanover, NH 03755-3551 (603) 646 - 3179

Directions: http://www.math.dartmouth.edu/~trs/choatehouse.html
Office hours: http://www.math.dartmouth.edu/~trs/frontmatter/office.html

#
#
# Sample configuration file for the Common UNIX Printing System (CUPS)
# scheduler. See "man cupsd.conf" for a complete description of this
# file.
#

# Log general information in error_log - change "info" to "debug" for
# troubleshooting...
LogLevel warning
#LogLevel debug2

# Administrator user group...
SystemGroup lpadmin

# Only listen for connections from the local machine.
# These settings are configured in /etc/cups/cups.d/ports.conf so that
# changing them does not require to change this file.
# Listen localhost:631
# Listen /var/run/cups/cups.sock

# Show shared printers on the local network.
# The 'Browsing' setting is configured in /etc/cups/cups.d/browse.conf
# so that changing it does not require to change this file.
# Browsing Off
BrowseOrder allow,deny
BrowseAllow @LOCAL
BrowseAddress @LOCAL

# Default authentication type, when authentication is required...
DefaultAuthType Basic

# Restrict access to the server...
<Location />
  Order allow,deny
  Allow localhost
  Allow @LOCAL
</Location>

# Restrict access to the admin pages...
<Location /admin>
  Order allow,deny
  Allow localhost
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
  AuthType Basic
  Require user @SYSTEM
  Order allow,deny
  Allow localhost
</Location>

# Set the default printer/job policies...
<Policy default>
  # Job-related operations must be done by the owner or an adminstrator...
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

  # All administration operations require an adminstrator to authenticate...
  <Limit Pause-Printer Resume-Printer Set-Printer-Attributes Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Add-Printer CUPS-Delete-Printer CUPS-Add-Class CUPS-Delete-Class CUPS-Accept-Jobs CUPS-Reject-Jobs CUPS-Set-Default>
 ...

[Ante Karamatić (ivoks)]

You are missing:

Listen /var/run/cups/cups.sock

in /etc/cups/cups.d/ports.conf

Could you please add that, restart CUPS and try again? Thanks.

[trshemanske (thomas-r-shemanske)]

Ante Karamatić wrote:
> You are missing:
>
> Listen /var/run/cups/cups.sock
>
> in /etc/cups/cups.d/ports.conf
>
> Could you please add that, restart CUPS and try again? Thanks.
>

I am afraid there is no change in behavior

TRS

[Peter Cherriman (pjcherriman)]

I getting almost the exactly the same problem since I've upgraded from breezy to dapper.

I've also noticed that once a constant amount of network traffic between the printer and the ubuntu PC which continues until I kill the processes owned by cupsys printing for user pjc.

http://192.168.1.201:631/EPSON_IPP_Printer 104 pjc 1 Resolution=600x600dpi PageRegion=A4 InputSlot=Default Halftoning=Grayscale PageSize=A4 orientation-requested=3 sides=two-sided-long-edge job-uuid=urn:uuid:1c49cbe7-eddd-3010-7484-77f2db4390f6

[Ante Karamatić (ivoks)]

What versions of CUPS are on printer server?

[trshemanske (thomas-r-shemanske)]

Ante Karamatić wrote:
> What versions of CUPS are on printer server?
>

  dpkg -l | grep cupsys
ii cupsys 1.2.2-0ubuntu0.6.06 Common
UNIX Printing System(tm) - server
ii cupsys-bsd 1.2.2-0ubuntu0.6.06 Common
UNIX Printing System(tm) - BSD comman
ii cupsys-client 1.2.2-0ubuntu0.6.06 Common
UNIX Printing System(tm) - client pro
ii cupsys-driver-gutenprint 5.0.0~rc2-0ubuntu6 printer
drivers for CUPS
ii libcupsys2 1.2.2-0ubuntu0.6.06 Common
UNIX Printing System(tm) - libs

[Jouni Mettala (jouni-mettala)]

My friend have laserjet 1200 connected with paraller port. The problem he has might be wrong permissions of /etc/cups/cups.d/ports.conf or something like that.

[Jouni Mettala (jouni-mettala)]

> My friend have laserjet 1200 connected with paraller port. The > problem he has might be wrong permissions of
> /etc/cups/cups.d/ports.conf or something like that.

Solved with updates? or/and changing permissions and cupsys restart

[Peter Cherriman (pjcherriman)]

Jouni,

I think you maybe confusing matters.

I think the initial reporter and myself are talking about sending jobs to network printers using the IPP protocol.

I have a printer connect via parallel and ethernet to my dapper machine. The parallel port queue works perfectly, the other queue (ipp via ethernet to the printer) jobs never complete.

[jbakuwel (jan-bakuwel)]

I can confirm these findings. Printing from Ubuntu Dapper to a HP PSC950 connected via USB and a print server with ipp. Are there any more requests for additional information?

[Alex van Niel (alexvanniel)]

I have the same problem. Although I do not experience the high cpu amount, I do have a job lingering in the print job window after job completion. When I cancel the job and a new job was issued, the new job is finally printed. Please fix this because it is a bit annoying to have a job printed upon restarting after forgetting to cancel a completed job.

[Peter Cherriman (pjcherriman)]

What info are we waiting for on this bug?

I'm seeing effectively the same problem.

My printer is connected via parallel port and via the ethernet port on the printer.

If I send a job via the IPP protocol directly to the printer's EpsonNet interface, the job prints but is never removed from the print queue, and the printer reports it is waiting for completion in the gnome print manager. This was not problem in breezy.

I can manually remove the job from the printer queue. This sometime causes the HTTP cups process to burn cpu cycles, but not always. However it does continue to generate network traffic until it is killed. The process is of the form:

http://192.168.1.201:631/EPSON_IPP_Printer 104 pjc 1 Resolution=600x600dpi PageRegion=A4 InputSlot=Default Halftoning=Grayscale PageSize=A4 orientation-requested=3 sides=two-sided-long-edge job-uuid=urn:uuid:1c49cbe7-eddd-3010-7484-77f2db4390f6

This maybe due to the printserver in my Epson EPL5800 printer's network card not reporting completion, but as I said it wasn't a problem in breezy.

The printer works perfectly it I use LPD protocol instead of IPP via the ethernet interface or using the parallel port interface.

So this maybe a subtle bug in the http backend which does handle some IPP printservers which may not be fully compliant.

pjc@ubuntu:~$ lpinfo -v
network socket
network beh
network http
network ipp
network lpd
direct parallel:/dev/lp0
direct canon:/dev/lp0
direct epson:/dev/lp0
network smb

So is then any info that I can provide to help fix this bug?

[jbakuwel (jan-bakuwel)]

Hi Peter,

I'm not sure who is waiting for what. The bug is (still) here. I'd be
more than happy to provide more info but it seems no one is listening?

brgds,
Jan

Peter Cherriman wrote:
> What info are we waiting for on this bug?
>
> I'm seeing effectively the same problem.
>
> My printer is connected via parallel port and via the ethernet port on
> the printer.
>
> If I send a job via the IPP protocol directly to the printer's EpsonNet
> interface, the job prints but is never removed from the print queue, and
> the printer reports it is waiting for completion in the gnome print
> manager. This was not problem in breezy.
>
> I can manually remove the job from the printer queue. This sometime
> causes the HTTP cups process to burn cpu cycles, but not always. However
> it does continue to generate network traffic until it is killed. The
> process is of the form:
>
> http://192.168.1.201:631/EPSON_IPP_Printer 104 pjc 1
> Resolution=600x600dpi PageRegion=A4 InputSlot=Default
> Halftoning=Grayscale PageSize=A4 orientation-requested=3 sides=two-
> sided-long-edge job-uuid=urn:uuid:1c49cbe7-eddd-3010-7484-77f2db4390f6
>
> This maybe due to the printserver in my Epson EPL5800 printer's network
> card not reporting completion, but as I said it wasn't a problem in
> breezy.
>
> The printer works perfectly it I use LPD protocol instead of IPP via the
> ethernet interface or using the parallel port interface.
>
> So this maybe a subtle bug in the http backend which does handle some
> IPP printservers which may not be fully compliant.
>
> pjc@ubuntu:~$ lpinfo -v
> network socket
> network beh
> network http
> network ipp
> network lpd
> direct parallel:/dev/lp0
> direct canon:/dev/lp0
> direct epson:/dev/lp0
> network smb
>
> So is then any info that I can provide to help fix this bug?
>
>

[Sjors Robroek (sjors)]

We are encountering the following bug as well. Every now and then 2 ipp processes keep running on the cups server and eating 100% cpu time. Stracing the processes show the following:

recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152
recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152
recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152
recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152
recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152
recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152
recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152
recvfrom(4, "", 2048, 0, NULL, NULL) = 0
time(NULL) = 1173275152

ad nauseum.

This is a serious showstopper for us, considering we never had this problem before, and this problem causes the cups service to be unavailable, and other services to become hardly accessibly (load shoots up to 10+ within 15 minutes).

I've already tried backporting cups 1.2.8 from feisty to dapper, but this didn't seem to help anything.

[Till Kamppeter (till-kamppeter)]

Can you boot with a Feisty live CD and see whether the problem occurs there?

[Sjors Robroek (sjors)]

No, unfortunately this is a live system. I'd guess it would be fixed in feisty, but we're not just ready yet to upgrade our server.

It will be replaced in a few months or so, so i'm hoping it's fixed in edgy.

[Till Kamppeter (till-kamppeter)]

Probably the problem is caused by bugs in the printer's implementation of IPP, so as long as upstream CUPS does not do a work-around in their IPP backend, the best is to use one of the other communication protocol of the printer.

Can everyone of you who reported the problem with printing via IPP run

/usr/lib/cups/backend-available/snmp

Which URI does this program suggest for your printer? If you do not get any answer or only answers from printers which do not have this problem, add the IP of your printer to the command line above.

"snmp" is a network printer auto-detection backend which was introduced with CUPS 1.2. It does not only find the printers but also tries to suggest the most suitable communication protocol (IPP, TCP/Socket, or LPD). During the tine (nearly one year) of the existence of this program many bugs and incompatibilities of the printer's implementations of the network protocols were discovered and now they are taken into account by the "snmp" backend. So it is recommended to use the protocol which "snmp" suggests.

In current Feisty (cupsys >= 1.2.8-0ubuntu3, gnome-cups-manager >= 0.31-3ubuntu3) this backend is activated for use by default. Both the gnome-cups-manager and the web interface of CUPS (http://localhost:631/) make use of "snmp" and show network printers in their lists of detected printers. So users are automatically led to use a protocol which the printer supports correctly.

[Sjors Robroek (sjors)]

It recommends IPP, but that's most likely because the printers have lpd and tck disabled to prevent abuse.

They're all network printers, so sockets are no option. If the problem persists i might switch to using ldp, but it's not preffered.

Just one question: does the snmp backend in feisty also work if you're using a centralized cups server with broadcasts & browsing on the clients? or will you have to enable the snmp backend on the cups server then?

[Sjors Robroek (sjors)]

result of the snmp backend fyi:

root@eckhout:~# /usr/lib/cups/backend-available/snmp
INFO: Using default SNMP Address @LOCAL
INFO: Using default SNMP Community public
network ipp://xxx.xxx.xxx.xxx:631/ipp "HP Color LaserJet 4550" "HP Color LaserJet 4550 xxx.xxx.xxx.xxx" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP Color LaserJet 4550 ;CLS:PRINTER;DES:Hewlett-Packard Color Lase"
network ipp://xxx.xxx.xxx.xxx/ipp "HP LaserJet 8150 Series" "HP LaserJet 8150 Series xxx.xxx.xxx.xxx" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:HP LaserJet 8150 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet 8150 "
root@eckhout:~#

[Peter Cherriman (pjcherriman)]

The problem maybe caused by bugs in the printer's implementation of IPP. However my printer worked perfectly well using IPP under breezy. I get this bug on dapper though (see my previous posts in the bug report - Bug #43352). So I guess the http backend program changed in such a way that it didn't like mine and other printers' IPP stacks. My printer works fine using lpd under dapper.

On my dapper machine with cupsys 1.2.2-0ubuntu0.6.06 I get:

user@ubuntu:~$ sudo /usr/lib/cups/backend-available/snmp
INFO: Using default SNMP Address @LOCAL
INFO: Using default SNMP Community public
network ipp://192.168.1.201:631/EPSON_IPP_Printer "EPSON EPL-5800" "EPSON EPL-5800 192.168.1.201" ""

[trshemanske (thomas-r-shemanske)]

Curiously, I get no response from the snmp command, despite the fact
that lpstat sees the hp1200

user@GX260:~$ sudo /usr/lib/cups/backend-available/snmp 192.168.1.2
INFO: Using default SNMP Community public

user@GX260:~$ sudo /usr/lib/cups/backend-available/snmp
INFO: Using default SNMP Address @LOCAL
INFO: Using default SNMP Community public

user@GX260:~$ lpstat -s
system default destination: hp1200
device for hp1200: lpd://192.168.1.2/lpt3
device for PSC-2175: hp:/usb/PSC_2170_Series?serial=MY366C90YY73

[Bram Metsch (metsch)]

We watch this problem especially if the title of the printed document conatins an umlaut.
Maybe this Cups STR describes the problem:
http://www.cups.org/str.php?L1837

[Sjors Robroek (sjors)]

I have had the same problem for quite a while, it seems like the cause is the same as Bram Metsch. Unfortunately, i cannot apply the fix provided in the STR you linked, so i am hoping to find a workaround. Is there any way to sanitize a document before it's passed to IPP?

[Till Kamppeter (till-kamppeter)]

In CUPS 1.2.11 this problem is fixed (CUPS version of current Gutsy).

On older versions it is recommended to set up print queues with the TCP/Socket protocol. So modify the queue to use the Socket protocol. If needed, use the printer's web interface to activate Socket support in the printer.