Bug#908147: restarting cups-browsed deleted print jobs
Anthony, thanks for testing. The fix is on its way into Debian and Ubuntu. Till
Bug#908147: restarting cups-browsed deleted print jobs
On 12/5/18 4:49 PM, Till Kamppeter wrote: cups-browsed is part of cups-filters, not of CUPS. The patch you find here: https://github.com/OpenPrinting/cups-filters/commit/0d29084a864ca80ada8b4eafc2d36f072e06f984 I applied your patch and it has fixed the problem for me. Thank you!
Bug#908147: restarting cups-browsed deleted print jobs
Le mercredi, 5 décembre 2018, 22.49:57 h CET Till Kamppeter a écrit : > cups-browsed is part of cups-filters, not of CUPS. The patch you find here: > > https://github.com/OpenPrinting/cups-filters/commit/0d29084a864ca80ada8b4eaf > c2d36f072e06f984 I'm uploading a fixed cups-filters with this patch cherry-picked "as we speak". Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#908147: restarting cups-browsed deleted print jobs
cups-browsed is part of cups-filters, not of CUPS. The patch you find here: https://github.com/OpenPrinting/cups-filters/commit/0d29084a864ca80ada8b4eafc2d36f072e06f984 Till
Bug#908147: restarting cups-browsed deleted print jobs
On 12/5/18 4:20 PM, Till Kamppeter wrote: Anyone suffering this problem, can you apply my upstream fix and check again whether this solves the problem? Thanks. Till I can't find 0d29084a864c anywhere. I checked: * https://github.com/apple/cups * https://github.com/tillkamppeter/cups * https://salsa.debian.org/printing-team/cups Could you please point to where you've published it (or, alternatively, email the patch). I hope it applies against 2.2.9 which Debian currently has, or this could get interesting.
Bug#908147: restarting cups-browsed deleted print jobs
Anyone suffering this problem, can you apply my upstream fix and check again whether this solves the problem? Thanks. Till
Bug#908147: restarting cups-browsed deleted print jobs
On 12/5/18 3:41 PM, Till Kamppeter wrote: Anyone here who can reproduce the vanishing of print jobs when stopping or restarting cups-browsed, please put cups-browsed in debug logging mode by stopping it, editing /etc/cups/cups-browsed.conf to contain a line DebugLogging file I've attached three cups-browsed_log logs and my cups-browsed.conf. The three logs were made from four restarts of cups-browsed. After each start, I did a "mv cups-browsed_log cbl-N" to keep each start separate (it kept writing to the same file after mv): (a) un-comment DebugLogging file, restart [finishes none, this starts log #1] (b) pause printer, send print job, restart cups-browsed [finishes #1, starts #2] (c) pause printer, send print job, restart cups-browsed [finishes #2, starts #3] (d) comment back out DebugLogging, restart [finishes #3, starts none] The print job from (b) was preserved and sent on; the print job from (c) was lost. PS: On the off-chance the implicitclass being lowercased every other restart was a cause, I created a second PDF queue "lcpdf" on Watt, so that there wouldn't be a miss-match every other restart. That one always displays lowercase, but it still exhibits the every-other-restart behavior w/r/t/ deleting jobs. cups-browsed.conf.gz Description: application/gzip cbl-1.gz Description: application/gzip cbl-2.gz Description: application/gzip cbl-3.gz Description: application/gzip
Bug#908147: restarting cups-browsed deleted print jobs
I have (hopefully) fixed this bug upstream now (commit 0d29084a864c). In case of a shutdown of cups-browsed the queues were even removed with jobs. This I have corrected now, now cups-browsed really only removes print queues when they do not have jobs. The problem occurred independent of whether the remote queues are discovered from the local network or via BrowsePoll. Till
Bug#908147: restarting cups-browsed deleted print jobs
On Wed 05 Dec 2018 at 15:13:53 -0500, Anthony DeRobertis wrote: > Actually, I'm using cups-browsed's BrowsePoll here, the printers are on > another network over a VPN. I have no idea if that matters. Of course it matters. I would never have entered this conversation if I had known that. VPN's are outside my experience, and I have no plans to explore further. > The alternative to using cups-browsed for that use case is, so far as I > know, to just configure the printers statically. I prefer not to, as that > means copying around a bunch of config. > > I'm glad someone else is seeing this too, though. Especially after > determining it was deleting jobs every other restart I was beginning to > worry that I might just be a crazy person :-/ I most probably will look at this further, but only without BrowsePoll and a VPN. -- Brian.
Bug#908147: restarting cups-browsed deleted print jobs
Usually cups-browsed does not remove a print queue if it still has jobs. If it is stopped and one of its queues still has jobs, this queue is left intact. Next time it starts it connects the this remaining queue with its printer if it re-discovers the printer, or removes it if the printer has disappered (also only when there are no jobs). Anyone here who can reproduce the vanishing of print jobs when stopping or restarting cups-browsed, please put cups-browsed in debug logging mode by stopping it, editing /etc/cups/cups-browsed.conf to contain a line DebugLogging file and start it again. Then do all the reproducer steps as described in the previous postings here and after that, attach your /etc/cups/cups-browsed.conf to this bug report. Thanks. Till
Bug#908147: restarting cups-browsed deleted print jobs
Actually, I'm using cups-browsed's BrowsePoll here, the printers are on another network over a VPN. I have no idea if that matters. The alternative to using cups-browsed for that use case is, so far as I know, to just configure the printers statically. I prefer not to, as that means copying around a bunch of config. I'm glad someone else is seeing this too, though. Especially after determining it was deleting jobs every other restart I was beginning to worry that I might just be a crazy person :-/
Bug#908147: restarting cups-browsed deleted print jobs
On Wed 05 Dec 2018 at 12:06:39 -0500, Anthony DeRobertis wrote: > 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. More or less the same for me, but I have no explanation. It is not compulsory to use cups-browsed; 'lpstat -e' should show your print queue when it is stopped. 'lp -d PDF_watt_home' might be a way of of getting the job done. Regards, Brian.
Bug#908147: restarting cups-browsed deleted print jobs
On Sat 01 Dec 2018 at 18:04:15 +0100, 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.) I would doubt the init system is a factor. Additionally, your print queue/printer is not on the local network so discovery via Bonjour broadcasting is not involved, as it would seem to be with Anthony DeRobertis. So, I am unsure how pertinent your observation is. > Cheers, > gregor, from the Bern BSP Thanks for your participation in the BSP. All work and no beer I imagine. Or did Odyx buy you a few? :) Regards, Brian.
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
Bug#908147: restarting cups-browsed deleted print jobs
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 -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#908147: restarting cups-browsed deleted print jobs
Package: cups-browsed Version: 1.21.1-1 Severity: grave I had an two jobs of online receipts set to print to a cups-browsed remote print queue (a PDF printer on a remote machine), and a bit after printing noticed that print handn't completed. I checked the local CUPS status page and saw a message that cups-pdf hadn't provided a host name, confirm it is running (compare bug #887495). I checked (via systemctl status), it was running: root@Zia:~# systemctl status cups-browsed.service ● cups-browsed.service - Make remote CUPS printers available locally Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-09-06 00:00:04 EDT; 13h ago Main PID: 31796 (cups-browsed) Tasks: 3 (limit: 4915) Memory: 5.0M CGroup: /system.slice/cups-browsed.service └─31796 /usr/sbin/cups-browsed Sep 06 00:00:04 Zia systemd[1]: Started Make remote CUPS printers available locally. ... since it wasn't working, I did the obvious thing: systemctl restart cups-browsed.service 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. So it appears restarting cups-browsed deletes all pending print jobs. Unfortunately, they're just gone ... hope I don't need those receipts. A test page now works, so at least it fixed the queue. Testing restarting it again, the job history is indeed gone, so that confirms its deleting the data. Unexpectedly and without warning discarding user data (pending print jobs) really isn't OK, especially when CUPS itself is suggesting the action that led to it. Also, it looks like it was automatically restarted yesterday & this morning at midnight; that makes this worse. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups-browsed depends on: ii cups-daemon 2.2.8-5 ii libavahi-client3 0.7-4 ii libavahi-common3 0.7-4 ii libavahi-glib10.7-4 ii libc6 2.27-5 ii libcups2 2.2.8-5 ii libcupsfilters1 1.21.1-1 ii libglib2.0-0 2.56.1-2 ii libldap-2.4-2 2.4.46+dfsg-5 ii lsb-base 9.20170808 Versions of packages cups-browsed recommends: ii avahi-daemon 0.7-4 cups-browsed suggests no packages. -- Configuration Files: /etc/cups/cups-browsed.conf changed: BrowseRemoteProtocols dnssd cups BrowsePoll watt.home -- no debconf information
