Created attachment 1969773 [details]
PPD used on upstream print server

Created attachment 1969774 [details]
PPD generated by everywhere driver

Created attachment 1969775 [details]
PPD file generated by cups-browsed (driverless driver)

Hi!

Thank you for taking the time to report this issue to us. We appreciate the feedback and use reports such as this one to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution.

If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution.

For information on how to contact the Red Hat production support team, please visit:
    https://access.redhat.com/support

To increase chance a fix for an issue in Red Hat Enterprise Linux or CentOS Stream is included, consider contributing to CentOS Stream. Red Hat engineers will review your issue based on the following steps:
    https://docs.centos.org/en-US/stream-contrib/quickstart/#_1_file_a_bugzilla
and if agreed the change meets criteria for being included, you can create a merge request for the selected component at:
    https://gitlab.com/redhat/centos-stream
referencing this issue. Red Hat engineers will review your merge request and consider merging it if the code passes a review and further testing.


Upstream server has CUPS 2.2.10 - it is not a version which is in any RHEL - what OS is it? Or did you install a new CUPS version by yourself?

Next, it would be great if you provided the file which is sent to RHEL 9 machine from Windows - it is located in /var/spool/cups, its name starts with 'd' and then continues job id and then sequence number of the file in the job, f.e.:

You send one file for printing, CUPS gives it job number 18, so the 'd' filename will be 'd00018-001'.

Next, it would be great if you got couple of logs from RHEL 9 client and upstream server when you print from Windows:

- one couple of logs (one from RHEL 9 and one from upstream server) when you print a specific file via everywhere queue from Windows,
- one couple of logs (one from RHEL 9, one from upstream server) when you print the same file via driverless (generated by cups-browsed) queue from Windows.

You can set debug logging by:

$ cupsctl LogLevel=debug2

and then turn it off (once you're done collecting logs) by "cupsctl LogLevel=warn".

The key is that one couple of logs represents one printing from Windows, so I can follow the flow via logs, and both couples represents two different print jobs, but both will print the same file.

Created attachment 1969939 [details]
Logs as requested

Hi Zdenek,

Thanks for your response.

(In reply to Zdenek Dohnal from comment #4)
> Upstream server has CUPS 2.2.10 - it is not a version which is in any RHEL -
> what OS is it? Or did you install a new CUPS version by yourself?

The upstream server is a Debian server.

> Next, it would be great if you provided the file which is sent to RHEL 9
> machine from Windows - it is located in /var/spool/cups, its name starts
> with 'd' and then continues job id and then sequence number of the file in
> the job, f.e.:
> 
> You send one file for printing, CUPS gives it job number 18, so the 'd'
> filename will be 'd00018-001'.
> 
> Next, it would be great if you got couple of logs from RHEL 9 client and
> upstream server when you print from Windows:
> 
> - one couple of logs (one from RHEL 9 and one from upstream server) when you
> print a specific file via everywhere queue from Windows,
> - one couple of logs (one from RHEL 9, one from upstream server) when you
> print the same file via driverless (generated by cups-browsed) queue from
> Windows.

I've attached the files you have requested as attachment 1969939 [details].

The zip file contains the following files:

testpage.pdf is the file that was printed from a Windows 10 machine using Edge.

The driverless directory contains the files and logs from the job to the driverless queue:
 - el9-cups.log is the cups log on the EL9 machine
 - upstream-cups.log is the cups log on the upstream cups server
 - ulsysgrp.ppd is the ppd file generated by cups-browsed on the EL9 machine
 - upstream-c938460 is the metadata file from the CUPS spool on the upstream print server
 - el9-c00013 and el9-d00013-001 are the spool files on the EL9 system

In the EL9 cups logs, the "bad" job is job 13.

The everywhere directory contains the similar files for the same job printed to the everywhere queue (testqueue.ppd). This queue was created using:

lpadmin -p testqueue -v ipp://printserv.esat.kuleuven.be:631/printers/ulsysgrp -m everywhere -E

I hope this includes the information you need.

Regards,
Rik

Ok, I was able to reproduce the issue. Implicitclass backend enforces pdf document format as output format, but it doesn't do any conversions, so it sends pcl file claiming it is PDF file in IPP packet, which gets stuck on the server, because the server's print queue accepts only PCL based on PCL driver.

IMO implicitclass backend could do IPP request to the destination about document-format-supported, and if the destination supports the same document format as the incoming file has, it will use this format.

I'll talk about it upstream and come with the patch, but in case you would like to prioritize the fix and have RHEL subscription, please file customer case on customer portal https://access.redhat.com , or send PR according https://docs.centos.org/en-US/stream-contrib/ .


How to reproduce:
- 2 machines, client - server


Server:
$ sudo dnf -y install cups
# enable file device
$ sed -i 's,#FileDevice No,FileDevice Yes,' /etc/cups/cups-files.conf 
$ sudo systemctl start cups
$ lpadmin -p test -v file:/tmp/ps -m drv:///sample.drv/generpcl.ppd -E
$ cupsctl --remote-any

Client:
$ sudo dnf -y install cups
$ echo 'BrowsePoll <server's ip>' >> /etc/cups/cups-browsed.conf
$ sudo systemctl start cups-browsed
$ sleep 5
$ lpstat -v
<shows the printer with implicitclass backend>
$ lp -d <printer> /usr/share/cups/ipptool/testfile.pcl.gz
$ sleep 30
$ lpstat -o

Actual result f.e.:
test-2                  root              4096   Tue 18 Jul 2023 01:17:51 PM UTC

Expected result:
No job hanging.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.