View Issue Details

IDProjectCategoryView StatusLast Update
0010226CentOS-7cupspublic2016-01-24 04:18
Reportergennis Assigned To 
PriorityhighSeveritymajorReproducibilityrandom
Status newResolutionopen 
PlatformlinuxOSCentos 7OS Version3.10.0-327.4.4.e
Product Version7.2.1511 
Summary0010226: cups-1.3.7-32.el5_11.x86_64 randomly duplicates print jobs sometimes as many as 500 times
DescriptionI have a problem I have been chasing for about three weeks and only
occurred after cups was updated with cups-1.6.3-22.el7. I would be
interested as to whether any one else has had this problem, and would
entertain suggestions as to how I can debug the problem.

My Centos 5 server is a gateway as well as a cups print server that has
been in place for 8 years and has continued to perform exceptionally
well.

My Centos 7 server is a mail server and archive file server that is in
the same network as my Centos 5 server described above. I have cups
active on this server, which communicates to the Centos 5 server
described above as well as another remote Centos 5 cups print server and
another remote Centos 6 cups print server. Each of the latter two print
servers are on different networks than the Centos 7 server that has the
problem.

The problem that has been occurring for the last three weeks appears to
be related to the Centos 7 server or communication failure between it
and the Centos 5 print server in the same network. What happens is that
when the Centos 7 archive server receives a command to print an archived
file on one of the printers inside its own network it appears to send
several print commands to the Centos 5 server which causes the file to
be printed several times. What happens is that the users eventually
turn off the printer to keep the file from being printed dozens of
times, and eventually the cups print queue on the Centos 5 server
becomes full and all the printers in that network become unreachable
with print commands. It is interesting that the remote print servers
appear to function normally during this time.

The only way I have figured out to remedy the problem is the use the
"cancel -u user" command on the Centos 5 server to get rid of the
command on the Centos 5 server and to use cancel lpt2-xxxxx on the
Centso 7 server to get rid of the command on the archive server. When I
evaluate the logs, I am either blind to the problem or am not seeing
much I can piece together.

Both machines have all updates and are listed as :

Gateway and Cups Print Server :
CentOS release 5.11 (Final)
 with 2.6.18-407.el5.centos.plusxen kernel
 with cups-1.3.7-32.el5_11.x86_64

Mail server and Archive File server :
CentOS Linux release 7.2.1511 (Core)
  with 3.10.0-327.4.4.el7.x86_64 kernel
  with cups-1.6.3-22.el7.x86_64

If any of you have ideas, would sure appreciate your help.
Steps To ReproduceI have not been able to reproduce this on demand
Additional InformationI am suspicious that when cups-1.3.7-32.el5_11.x86_64 sends a file to cups-1.3.7-32.el5_11.x86_64, cups-1.3.7-32.el5_11.x86_64 is not receiving a finish command from cups-1.3.7-32.el5_11.x86_64, and then it sends the file again.

I have the logs set to debug and am not seeing any errors, but I certainly get duplicate print entries in the page_log :

lpt2 mail 3621 [21/Jan/2016:23:00:24 -0600] total 0 - localhost
smile.pr.d4UBof.o - -

lpt2 mail 3621 [21/Jan/2016:23:00:25 -0600] total 0 - localhost
smile.pr.d4UBof.o - -

lpt2 mail 3621 [21/Jan/2016:23:00:26 -0600] total 0 - localhost
smile.pr.d4UBof.o - -

lpt2 mail 3621 [21/Jan/2016:23:00:28 -0600] total 0 - localhost
smile.pr.d4UBof.o - -

lpt2 mail 3621 [21/Jan/2016:23:00:31 -0600] total 0 - localhost
smile.pr.d4UBof.o -
TagsNo tags attached.
abrt_hash
URL

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2016-01-24 04:18 gennis New Issue