Open archenemies opened 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.
Hi. I tried recreating this issue with a virtual printer with the following two files:
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
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
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.
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
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:
And the PPD on the client:
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.
@archenemies I tried the same using pdf files and it is printing only the first file as you said.
@archenemies Can you please share this file or check out whether it has u.pdf in the location /var/spool/cups/ as d00276-001?
@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.
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
.
@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.
I have a remote printer which I think was created with the following command:
Here is the entry from the local /etc/cups/printers.conf:
Here is the entry from the remote server:
When I try to print two files, on the local machine, like this:
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
The remote has
Here are the files:
t.pdf u.pdf
I tried regenerating the print queue and PPD with: