Bug#908147: restarting cups-browsed deleted print jobs
Just re-tested:
1. Went to http://localhost:631/printers/PDF_watt_home and under
"Maintenance" picked "pause printer". Entered username & password
when prompted.
2. Generated a print job with: fortune -s | lpr -PPDF_watt_home
3. Confirmed a print job in the queue at
http://localhost:631/printers/PDF_watt_home
4. Ran systemctl restart cups-browsed.service
5. Job stayed...
6. Ran systemctl stop cups-browsed.service ; systemctl start
cups-browsed.service
7. Job vanished.
That is... odd. So I tried printing another job, getting an "No
destination host name supplied by cups-browsed for printer
\"pdf_watt_home\", is cups-browsed running?" error showing up in the
CUPS error log (and webui) eventually. After that, "systemctl restart
cups-browsed.service" made the job vanish.
Now that printer seems permanently broken (with that no destination
error). So I restarted cups.service (which also deleted the print job).
Still got the error.
It's weird I'm also getting errors in the CUPS error log like:
E [05/Dec/2018:11:38:24 -0500] [Client 22] Returning IPP
client-error-bad-request for CUPS-Add-Modify-Printer
(ipp://localhost:631/printers/pdf_watt_home) from localhost.
To get it back working, I stopped cups-browsed.service, deleted all the
printers it added via CUPS webui, stopped cups.service, started
cups.service, and then started cups-browsed.service again. Got those
weird error log entries again.
After that, tested again and it didn't delete the job, but restarting
cups-browsed.service resumed the print queue (which it probably
shouldn't, since I manually paused it, but that's much more minor).
Just to be sure, paused it again, added another job, and restarted
cups-browsed.service: it deleted the job.
Tested again: unpaused, job not lost.
Tested again: job lost
Tested again: unpaused, not lost.
Tested again: job lost
Tested again: unpaused, not lost
... so... umm... it seems to lose jobs every other restart.
So I restarted it immediately again, without sending a print job. Then
tested again, and not lost. It really does appear to be every other restart.
I think I've noticed something though. On restarting it, the
"Connection:" changes in the CUPS web ui. Sometimes its
"implicitclass://pdf_watt_home/" other times
"implicitclass://PDF_watt_home/". Each restart of cups-browsed.service
changes back and forth. And it appears lowercased printer names lose
jobs on restart.
I have two remote printers, and they have opposite lowercase-states. I
haven't tested as much with the other printer (it's a real printer, so
testing wastes paper & toner), but it appears to follow the same
lowercase-means-jobs-lost rule. (BTW: It gets the error log entries too).
I tried to find more details about the bad requests, but it doesn't
appear to actually be sending IPP requests — or at least, not one that
Wireshark can capture on lo (it sees the requests from Firefox, so it's
working). Possibly it sends them over the cups UNIX socket.
On 12/1/18 12:04 PM, gregor herrmann wrote:
On Thu, 06 Sep 2018 13:31:51 -0400, Anthony DeRobertis wrote:
After doing so, the queue in the browser refreshed and showed empty. But
I checked — the PDFs were not created. Showing completed jobs shows
nothing. Looking in /var/spool/cups (on both the local machine and the
remote machine) shows no sign of the two jobs.
I can't reproduce this bug but maybe I did something wrong. What I
did was:
- print to a printer which is not available
- check in the cups web ui and in /var/spool/cups that the print job
is there
- service cups-browsed restart
- and the job is still in the spool and the web ui still shows the job
and the problem (printer not responding; well, it's a few hundred
kilometers away)
(In the spirit of full disclosure: this is with sysv-init and not
systemd, in case this makes a difference.)
Cheers,
gregor, from the Bern BSP
Reply to: