OpenPrinting / cups-filters

filters, backends, driverless utility, ... - Everything which CUPS 2.x needs to be used on non-Mac systems
Apache License 2.0
151 stars 122 forks source link

can't print multiple documents to remote printer #187

Open archenemies opened 4 years ago

archenemies commented 4 years ago

I have a remote printer which I think was created with the following command:

lpadmin -p B210_remote -m everywhere -E -v ipp://musa/printers/HP_Photosmart_Plus_B210_series

Here is the entry from the local /etc/cups/printers.conf:

<Printer B210_remote>
PrinterId 1
UUID urn:uuid:decf7f3e-2c3b-33a2-7123-70eb8df14aef
AuthInfoRequired none
Info HP Photosmart Plus B210 series
Location 
MakeModel Photosmart Plus b210 Series, hpcups 3.18.12 - IPP Everywhere
DeviceURI ipp://musa/printers/HP_Photosmart_Plus_B210_series
State Idle
StateTime 1578986695
ConfigTime 1578986947
Type 36940
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-current-job
</Printer>

Here is the entry from the remote server:

<Printer HP_Photosmart_Plus_B210_series>
UUID urn:uuid:3a964b59-4f10-3f5e-75e4-8ca35b418138
Info HP Photosmart Plus B210 series
MakeModel HP Photosmart Plus b210 Series, hpcups 3.18.12
DeviceURI hp:/usb/Photosmart_Plus_B210_series?serial=CN0AS2G4JJ05J9
State Idle
StateTime 1578986627
ConfigTime 1566084470
Type 36876
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-current-job
</Printer>

When I try to print two files, on the local machine, like this:

lp t.pdf u.pdf

only the first file is printed.

However, the same command with the same files on the remote machine prints both of them.

The local machine has

sudo less /var/log/cups/access_log
...
localhost - - [13/Jan/2020:23:33:23 -0800] "POST /printers/B210_remote HTTP/1.1" 200 331 Create-Job successful-ok
localhost - - [13/Jan/2020:23:33:23 -0800] "POST /printers/B210_remote HTTP/1.1" 200 10624 Send-Document successful-ok
localhost - - [13/Jan/2020:23:33:23 -0800] "POST /printers/B210_remote HTTP/1.1" 200 10617 Send-Document successful-ok

The remote has

192.168.42.9 - - [14/Jan/2020:07:33:23 +0000] "POST /printers/HP_Photosmart_Plus_B210_series HTTP/1.1" 200 398 Validate-Job successful-ok
192.168.42.9 - - [14/Jan/2020:07:33:23 +0000] "POST /printers/HP_Photosmart_Plus_B210_series HTTP/1.1" 200 363 Create-Job successful-ok
192.168.42.9 - - [14/Jan/2020:07:33:23 +0000] "POST /printers/HP_Photosmart_Plus_B210_series HTTP/1.1" 200 10606 Send-Document successful-ok

Here are the files:

t.pdf u.pdf

I tried regenerating the print queue and PPD with:

lpadmin -x B210_remote
sudo systemctl restart org.cups.cupsd.service
lpadmin -p B210_remote -m everywhere -o printer-error-policy=retry-current-job -E -v ipp://musa/printers/HP_Photosmart_Plus_B210_series
tillkamppeter commented 4 years ago

On both server and client please set CUPS into debug logging mode via

cupsctl --debug-logging

Print a job from the client. After that take the /var/log/cups/error_log files of both server and client and attach them here. Note that you have to rename them to have a .txt extension so that you can attach them to this issue.

sparshag21 commented 4 years ago

Hi. I tried recreating this issue with a virtual printer with the following two files:

test1.txt test2.txt

In this case the following command had the same outcome on both the client and the server when run separately on each.

lp test1.txt test2.txt

This is the output of the /var/log/cups/access_log.

On the client:

localhost - - [14/Mar/2020:02:31:51 +0530] "POST /printers/myprinter HTTP/1.1" 200 353 Create-Job successful-ok
localhost - - [14/Mar/2020:02:31:51 +0530] "POST /printers/myprinter HTTP/1.1" 200 275 Send-Document successful-ok
localhost - - [14/Mar/2020:02:31:51 +0530] "POST /printers/myprinter HTTP/1.1" 200 275 Send-Document successful-ok

On the server:

192.168.43.177 - - [14/Mar/2020:02:31:51 +0530] "POST /printers/myprinter HTTP/1.1" 200 515 Validate-Job successful-ok
192.168.43.177 - - [14/Mar/2020:02:31:51 +0530] "POST /printers/myprinter HTTP/1.1" 200 485 Create-Job successful-ok
192.168.43.177 - - [14/Mar/2020:02:31:51 +0530] "POST /printers/myprinter HTTP/1.1" 200 292 Send-Document successful-ok
192.168.43.177 - - [14/Mar/2020:02:31:51 +0530] "POST /printers/myprinter HTTP/1.1" 200 292 Send-Document successful-ok

The /var/log/cups/error_log files are also attached.

On the client: error_log_client.txt

On the server: error_log_server.txt

The version of cups I am using: 2.1.3

archenemies commented 4 years ago

Sorry this got lost in the shuffle.

On both server and client:

sudo cp -a /etc/cups/cupsd.conf{,.backup-2020-03-13}
sudo cupsctl --debug-logging   # warning! strips comments from config file
sudo systemctl stop org.cups.cupsd.service
sudo truncate --size 0 /var/log/cups/error_log
sudo systemctl start org.cups.cupsd.service
sudo cp -a /etc/cups/cupsd.conf{.backup-2020-03-13,}

On client:

lp -dB210_remote u.pdf t.pdf

rp musa:/var/log/cups/error_log musa-cups-error_log.txt
cp -a /var/log/cups/error_log ptolemy-cups-error_log.txt

Only u.pdf is printed.

Attaching log files. Version:

$ pacman -Qi cups                                                                                        ptolemy:~ 
Name            : cups
Version         : 2.3.1-1
Description     : The CUPS Printing System - daemon package
Architecture    : x86_64

ptolemy-cups-error_log.txt musa-cups-error_log.txt

Abhik1998 commented 3 years ago

Hey!! I tried to reproduce the issue and so I used Boomaga as a virtual printer. On the client:

lp -d Boomaga run.txt doit.txt

Error on ** : Can't read genNum

I tried out printing the same job multiple times:

lp -d Boomaga -n6 run.txt

This works out showing up the same file to be printed 6 times.

cups

This is the ouput of access_log:

localhost - - [06/Aug/2020:17:03:11 +0530] "POST /printers/Boomaga HTTP/1.1" 200 326 Create-Job successful-ok
localhost - - [06/Aug/2020:17:03:11 +0530] "POST /printers/Boomaga HTTP/1.1" 200 18366 Send-Document successful-ok

CUPS version : 2.3.3

archenemies commented 3 years ago

I still have the same problem, I send two simple PDF documents to my remote Brother printer and only the first is printed.

I noticed some attempts to reproduce the bug using .txt files; when I send two documents ending in .txt then only the second is printed.

If I print two documents with the same lp command on the server, they are both printed.

On the server, the cups version is:

$ apt show cups
Version: 2.2.10-6+deb10u2

On the client:

$ pacman -Qi cups
Name            : cups
Version         : 2.3.3-2

Here is the PPD on the server:

Brother_DCP-7065DN.ppd.txt

And the PPD on the client:

Brother_remote.ppd.txt

When I run lp I get a message about two files, I have never seen the genNum error message reported by @Abhik1998:

$ lp a.pdf b.pdf
request id is Brother_remote-229 (2 file(s))

Thanks.

Abhik1998 commented 3 years ago

@archenemies I tried the same using pdf files and it is printing only the first file as you said.

Abhik1998 commented 3 years ago

@archenemies Can you please share this file or check out whether it has u.pdf in the location /var/spool/cups/ as d00276-001?

archenemies commented 3 years ago

@Abhik1998 there is no file with that name on the client or server, but the original bug report is very old.

However, I find that the more recent a.pdf and b.pdf appear in /var/spool/cups on the client as:

d00227-001
d00227-002

They appear on the server, in the same directory, as:

d00454-001
d00454-002

Hope this helps.

surajkulriya commented 3 years ago

I didn't had a physical printer so I tried this issue using virtual CUPS-BRF-Printer which creates expected print files in $HOME/BRF directory. I tried to print two files a.pdf and b.pdf using lp a.pdf b.pdf. Only a single file a.pdf.xxxxx.brf was created in BRF directory with the content of b.pdf file. So I think it's overwriting the content of lp b.pdf on the output of lp a.pdf.

tillkamppeter commented 3 years ago

@surajkulriya, CUPS-BRF is part of the Braille embosser support. This is very different to regular printers. For testing without need of an actual printer, install the "cups-pdf" package of your distribution and create a print queue with this (if the installation process does not already create one automatically). This drops differently-named PDFs for each job printed in your ~/PDF directory and should in this case not get the second PDF overwriting the first.