Description of problem: Given a 2-page PDF file (e.g.: https://dl.dropboxusercontent.com/u/10969499/fox-pelican-lunch-menu-2015.pdf Okular happily prints Page 1 (on local USB HP5520), but when asked to print page 2 it freezes (as does HP Print Manager if then called). Also, if both HP Print Manager and Okular are then terminated, Page 2 prints! Version-Release number of selected component (if applicable): okular-4.14.3-2.mga5.src.rpm How reproducible: Steps to Reproduce: 1. Give Okular a PDF file (see example above). 2. Ask it to print 'from 1 to 1'. Successful. 3. Ask it to print 'from 2 to 2'. Nothing seems to happen, but if then call HP Print Manager, it, too, freezes with an empty window, and Okular is unresponsive. 4. Force Okular and HP Print Manager to terminate. 5. Page 2 is then printed! Reproducible: Steps to Reproduce:
CC: (none) => maurice
N.B. There are related bug reports elsewhere: Debian: 740707 KDE: 329740
Does it happen if you print something from another KDE application? Does it happen if you print a PDF from evince?
I can confirm this issue (with Okular at least, but I haven't tried with another PDF viewer). (In reply to Maurice Batey from comment #1) > N.B. There are related bug reports elsewhere: > > Debian: 740707 > KDE: 329740 Please give the full links, it's easier to check them out... Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740707 KDE: https://bugs.kde.org/show_bug.cgi?id=329740
Same issue here on mga5 for x86_64 and kde-4.14.3, There is also another odd behavior with okular: 1) if you click on "File -> Print Previous" with a pdf file the window remains empty. 2) with some pdf files printing does not work because the sheet remains blank/empty (no printing done). I confirm that this behavior is only with okular.
CC: (none) => geiger.david68210
> Does it happen if you print something from another KDE application? No problem printing same files from same PDF to same printer under LibreOffice Writer. (Also no problem if ask Okular to just print Page 2. I read somnwehere else of a suspicion that Okular is waiting on some printer state when it shouldn't/needn't do that, so after printing Page 1 it is endlessly waiting on some event.) > Does it happen if you print a PDF from evince? I know nothing about evince except that I believe it's a Gnome app.
P.S. https://bugs.kde.org/show_bug.cgi?id=3297400 has this posting: (Anssi Hannula 2015-04-15 21:37:00 UTC) On Mageia, the following stopgap measure was applied in Jan 2015 until this is properly fixed: http://svnweb.mageia.org/packages/cauldron/okular/current/SOURCES/okular -4.14.3-revert-show-paper-size-names-to-avoid-freeze.patch?revision= 811673&view=markup - so the Okular Mageia-5 is using presumably has that fix.
(In reply to Maurice Batey from comment #6) > (Anssi Hannula 2015-04-15 21:37:00 UTC) > On Mageia, the following stopgap measure was applied in Jan 2015 until > this is properly fixed: > http://svnweb.mageia.org/packages/cauldron/okular/current/SOURCES/okular > -4.14.3-revert-show-paper-size-names-to-avoid-freeze.patch?revision= > 811673&view=markup > > - so the Okular Mageia-5 is using presumably has that fix. Well we all seem to experience the bug on Mageia 5, so I guess this is yet another bug.
(In reply to Maurice Batey from comment #5) > > Does it happen if you print a PDF from evince? > > I know nothing about evince except that I believe it's a Gnome app. What was implied is you could have installed it and tested it.
> Does it happen if you print a PDF from evince? No problem with evince in that respect, though otherwise it's nowhere near as good an app as Okular. :-)
Just tested again with a Canon Pixma iP4500, and I get the same issue with Okular, so it's probably not printer-specific.
Comment in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740707 : "I found that it's due to it waiting on a socket: poll([{fd=15, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout) which goes on for a long time. According to lsof, it's trying to talk to the print server: okular 27987 madduck 15u IPv4 3586963 0t0 TCP 192.168.43.164:35068->192.168.14.2:ipp (SYN_SENT) which is unreachable, for obvious reasons (different RFC1918 net). ... I don't think okular should be talking to the print server anyway, that's cups' job, and cups properly handles disconnections and roaming between network, unreachable printers and other exceptions. Okular should not try to do itself what others are already doing, especially not if it doesn't end up doing it properly."
See Also: (none) => http://bugs.debian.org/740707
Okular has a ugly bug that it's becoming slow or not properly working if there is a configured network printer that for any reasons is unreachable, so maybe for someone of you, the problem is there. (comment #11 indeed)
CC: (none) => anaselli
(In reply to Angelo Naselli from comment #12) > Okular has a ugly bug that it's becoming slow or not properly working if > there is a configured network printer that for any reasons is unreachable, > so maybe for someone of you, the problem is there. It's not only networked though, my issue in comment 10 is with a USB plugged printer.
Possibly not an okular issue, second page prints fine here (same version). Difference is that it is a non-HP printer (Konica-Minolta 4750DN). This has a postscript interpreter so cups just has to transfer the postscript to the printer and no HP manager involvement, or cups backends to rasterise the postscript.
CC: (none) => deri
I confirm this bug on mageia5 X86-64 Okular happily prints Page 1 (on local USB MFC215 Brother), but when asked to print page 2 it freezes. Also, if Okular is killed, Page 2 prints!
CC: (none) => thierry.rouillon
Seeing similar behavior with Okular 32-bit, but under slightly different circumstances: (Marking this as a bug with "all," meaning both 64-bit and 32-bit.) 1. Click on a two-page pdf file with Okular as default application. 2. Print the file. (HP Deskjet 5650 usb printer or Officejet 6110 usb printer) 3. Start to print another copy. Change a print option, or leave everything alone. 4. Press the "Print" button. Okular freezes at this point. Also seeing this behavior with Gwenview and trying to print a second copy of a jpg image. Reported in https://bugs.mageia.org/show_bug.cgi?id=16673 which I now believe to be the same bug. Load a new pdf file into Okular or a new image file into Gwenview, and the new file will print normally - unless you try to print a second copy of it. I have two HP printers, both usb, and have seen the same behavior on both. I do not have a networked printer, so it can't be that.
CC: (none) => andrewsfarmHardware: x86_64 => All
(In reply to Thomas Andrews from comment #16) > Seeing similar behavior with Okular 32-bit, but under slightly different > circumstances: (Marking this as a bug with "all," meaning both 64-bit and > 32-bit.) > > 1. Click on a two-page pdf file with Okular as default application. > 2. Print the file. (HP Deskjet 5650 usb printer or Officejet 6110 usb > printer) > 3. Start to print another copy. Change a print option, or leave everything > alone. > 4. Press the "Print" button. Okular freezes at this point. > > Also seeing this behavior with Gwenview and trying to print a second copy of > a jpg image. Reported in https://bugs.mageia.org/show_bug.cgi?id=16673 which > I now believe to be the same bug. > > Load a new pdf file into Okular or a new image file into Gwenview, and the > new file will print normally - unless you try to print a second copy of it. > > I have two HP printers, both usb, and have seen the same behavior on both. I > do not have a networked printer, so it can't be that. Seeing the same behavior here on Mageia x86-64, but with a network printer Sharp AR-M351U. This problem does not exist until maybe a few weeks ago, if I remember correctly.
CC: (none) => piscestong
It is just possible that this is related to a cups bug, where cups uses up 100% of the cpu for long times at times. There is a bug fix for that on the cups.org web site STR#4605, which seems to work for me in stopping cups from using up everything. But I am also suspicious that that bug has further consequences than just using up cpu. Anyway someone might want to try compiling in that patch to see if it helps with the okular problem.
CC: (none) => unruh
(In reply to Deri James from comment #14) > Possibly not an okular issue, second page prints fine here (same version). > Difference is that it is a non-HP printer (Konica-Minolta 4750DN). This has > a postscript interpreter so cups just has to transfer the postscript to the > printer and no HP manager involvement, or cups backends to rasterise the > postscript. I hadn't noticed this bug when printing from okular, but most of the time, I use atrill. My printer is a Brother MFC-J825DW.
CC: (none) => laidlaws
Assigning to KDE maintainer. Nicolas, interesting bug report confirmed several times. See comment #11 for example.
Priority: Normal => HighCC: (none) => lmenutAssignee: bugsquad => mageiaSummary: Okular freezes after (suceessfully) printing page 1 of PDF and asked to print page 2 => freeze after (suceessfully) printing page 1 of PDF and asked to print page 2Source RPM: okular-4.14.3-2.mga5.src.rpm => cupsSeverity: normal => major
Summary: freeze after (suceessfully) printing page 1 of PDF and asked to print page 2 => Okular freezes after (suceessfully) printing page 1 of PDF and asked to print page 2Source RPM: cups => okular
(In reply to Thomas Andrews from comment #16) > Seeing similar behavior with Okular 32-bit, but under slightly different > circumstances: (Marking this as a bug with "all," meaning both 64-bit and > 32-bit.) > > 1. Click on a two-page pdf file with Okular as default application. > 2. Print the file. (HP Deskjet 5650 usb printer or Officejet 6110 usb > printer) > 3. Start to print another copy. Change a print option, or leave everything > alone. > 4. Press the "Print" button. Okular freezes at this point. > > Also seeing this behavior with Gwenview and trying to print a second copy of > a jpg image. Reported in https://bugs.mageia.org/show_bug.cgi?id=16673 which > I now believe to be the same bug. > > Load a new pdf file into Okular or a new image file into Gwenview, and the > new file will print normally - unless you try to print a second copy of it. > > I have two HP printers, both usb, and have seen the same behavior on both. I > do not have a networked printer, so it can't be that. Since I am seeing this in two applications, my untrained mind is wondering if the cups update ( https://bugs.mageia.org/show_bug.cgi?id=16152 ) that has languished in the Testing repos since July might fix the problem.
Created attachment 7082 [details] error log from trying to print from okular This is the cups/error_log from an attempt by me to print from okular. It was supposed to print 3 pages. As far as I an see cups never got the job at all. There was one notation on the command line (I started okular from the command line) that said lpr-cups: Success
I then ran okular under strace, but this time it worked and printed all three pages. I tried without strace, and it still worked. At no time did these working attempts print out that "lpr-cups: Success" line.
> Okular happily prints Page 1 (on local USB HP5520), but when asked to print > page 2 it freezes (as does HP Print Manager if then called). Just had precisely the same problem with KMail 4.14.5 on Mageia-5!
CC: (none) => yves.brungard_mageia
Same problem here with the second attempt to print from Okular. Using a USB printer BROTHER MFC9330. /vat/log/cups/error_log is empty since 19/07/2015
(In reply to Samuel Verschelde from comment #20) > Assigning to KDE maintainer. Nicolas, interesting bug report confirmed > several times. See comment #11 for example. Definitely some sort of KDE issue. I just checked, and I see the same behavior with both Kwrite and Kolourpaint. I have not yet noticed it in non-KDE apps like Gimp. w unruh speculated in comment 18 that it might be related to a bug where cups uses 100% of the CPU. Using Ksysguard to monitor CPU usage, I'm not seeing that. When an app fails to print the entire system seems to be idling, waiting for something.
I've the same behaviour also on Mageia release 5 (Official) for x86_64. I confirm Thomas comments above. I've also evince installed and evince does not have the problem. This seems pure KDE. Addotionnally, my (MCC defined) policy on the printer is "Abort Job" in case of error. Printer is not shared.
CC: (none) => gilles.duvert
is this bug still valid?
CC: (none) => marja11Blocks: (none) => 18367
On mga5 this bug is still valid yes.
Yes, it is. I work around it by using evince instead of Okular for mass printing.
I am running atril on the MATE desktop, so I wouldn't know. I will unsubscribe from this bug.
CC: laidlaws => (none)
Just re-tried printing page 1/2 and then page 2/2 of the test case: https://dl.dropboxusercontent.com/u/10969499/fox-pelican-lunch-menu-2015.pdf - and am glad to say they printed normally. So looks as though subsequent s/w updates on this 64-bit KDE Mageia-5 have provided a cure. Many thanks!
Still problems. cups-2.0.4-1.3.mga5.x86_64 okular-4.14.3-2.mga5 Printing odd pages of an 8 page pdf file, and then the even pages. The four odd pages printed. The next print job nothing came out. lpq froze. lpstat froze. (could ^C both of them) Okular also froze. Doing service cups restart restarted cups and the pages printed.
On the 25th of July, Phillipem uploaded the following packages to Cauldron's core/updates_testing: system-config-printer-1.5.7-5.mga6.i586 system-config-printer-applet-1.5.7-5.mga6.i586 system-config-printer-udev-1.5.7-5.mga6.i586 system-config-printer-libs-1.5.7-5.mga6.noarch system-config-printer-1.5.7-5.mga6.x86_64 system-config-printer-applet-1.5.7-5.mga6.x86_64 system-config-printer-udev-1.5.7-5.mga6.x86_64 @ Anyone reading this: * If this bug is valid for you in cauldron, then please test whether updating your system-config-printer packages to version 1.5.7-5.mga6 fixes the problem and report back in this bug report. * If you do not have this bug in cauldron, but you do run cauldron, then please update those packages, too, and report in bug 18367 whether they work as expected.
CC: (none) => makowski.mageia
Well, I reported this w.r.t. Mageia-5, so the mga6 files won't help there! But I shall check it out under Mga6-RC soon. (Your list implies that all 7 packages must be individually installed, rather than just system-config-printer itself? Will look up my notes on forcing install from a repo I don't normally enable...)
Installed the new system-config-printer packages from Core-Testing and checked Okular with same 2-page file as before, on 64-bit Mga6-RC. 1st page prints, but when selecting Print for 2nd page, Okular locks up, as before, so still no printing of 2nd page, I'm afraid. No replacement packages for Mga5, so can't check there yet.
Version: 5 => CauldronWhiteboard: (none) => MGA5TOO
See Also: (none) => https://bugs.kde.org/show_bug.cgi?id=329740
I do not have Cauldron installed on a computer with a printer, so I can't check this out. But, if Maurice is still seeing this here, I expect it is still valid for Bug #16673 and Gwenview. I can't say for sure, but I believe they are the same bug.
> No replacement packages for Mga5, so can't check there yet. Bug still present in fully-updated Mageia-5... (As I found when helping visitor (Windows user) print out some pages of a document. Most embarrassing for Linux... :-( )
P.S. This problem does not afflict the HP 1050 printer/scanner, by the way.
Assignee: mageia => kde
CC: lmenut => (none)
Hello, The problem is still valid on my Mageia 5. I tried during a freeze of okular trying to print the command : systemctl restart cups the printing which was stalling in Okular finished immediately and the page came from the printer. So I think that the problem is more cups than KDE applications.
One should be able to figure this out by looking at a debug file of cups. Ie, edit /etc/cups/cupsd.conf LogLevel debug in /etc/cups/cups-files.conf change the ErrorLog line to ErrorLog /var/log/cups/error_log Then restart cups Then print out a multipage document with okular, and at the freeze look at the error_log file to see if there is anything odd going on (eg only the first page showing up, etc)
In Mageia 5 Using system-config-printer from updates-testing. It works OK after printer 9 documents with Okular, but hangs at the 10th. The difference with the last is that I haven't closed the previous document. (Don't worry, the documents was needed ;) )
Created attachment 8377 [details] error.log from cups
I've just seen the same problem in KMail, when printing out one page of an HTML email and then trying to print the 2nd: KMail froze and no 2nd page printed. ('systemctl restart cups' cleared it up, though)
Done another try today. I confirm that there is no problem when closing the previous application and opening the second document to print with okular. The stall occurs when the first application is not yet closed, even if the second document is opened separately (with Okular, should it be as another application ?) After the first printing, I got in error.log: =========== [03/Sep/2016:12:55:26 +0200] [Client 638] Returning IPP successful-ok for CUPS-Get-Default (no URI) from localhost D [03/Sep/2016:12:55:26 +0200] [Client 638] Content-Length: 7675 D [03/Sep/2016:12:55:26 +0200] [Client 638] cupsdSendHeader: code=200, type="application/ipp", auth_type=0 D [03/Sep/2016:12:55:26 +0200] [Client 638] con->http=0x556632bbcdd0 D [03/Sep/2016:12:55:26 +0200] [Client 638] cupsdWriteClient error=0, used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=7675, response=0x556632bb7990(IPP_STATE_DATA), pipe_pid=0, file=-1 D [03/Sep/2016:12:55:26 +0200] [Client 638] Writing IPP response, ipp_state=IPP_STATE_DATA, old wused=0, new wused=0 D [03/Sep/2016:12:55:26 +0200] [Client 638] bytes=0, http_state=0, data_remaining=7675 D [03/Sep/2016:12:55:26 +0200] [Client 638] Flushing write buffer. D [03/Sep/2016:12:55:26 +0200] [Client 638] New state is HTTP_STATE_WAITING D [03/Sep/2016:12:55:26 +0200] [Client 638] Waiting for request. D [03/Sep/2016:12:55:26 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Active clients" D [03/Sep/2016:12:55:26 +0200] [Client 639] Accepted from localhost:60894 (IPv6) D [03/Sep/2016:12:55:26 +0200] [Client 639] Waiting for request. D [03/Sep/2016:12:55:26 +0200] [Client 640] Accepted from localhost:60895 (IPv6) D [03/Sep/2016:12:55:26 +0200] [Client 640] Waiting for request. D [03/Sep/2016:12:55:26 +0200] [Client 641] Accepted from localhost:60896 (IPv6) D [03/Sep/2016:12:55:26 +0200] [Client 641] Waiting for request. D [03/Sep/2016:12:55:26 +0200] [Client 642] Accepted from localhost:60897 (IPv6) D [03/Sep/2016:12:55:26 +0200] [Client 642] Waiting for request. [...] D [03/Sep/2016:12:55:27 +0200] [Client 659] Accepted from localhost:60914 (IPv6) D [03/Sep/2016:12:55:27 +0200] [Client 659] Waiting for request. ================ After 20 new clients sending requests, cups said: ================ W [03/Sep/2016:12:55:27 +0200] Max clients reached, holding new connections... D [03/Sep/2016:12:56:03 +0200] Report: clients=100 D [03/Sep/2016:12:56:03 +0200] Report: jobs=500 D [03/Sep/2016:12:56:03 +0200] Report: jobs-active=0 D [03/Sep/2016:12:56:03 +0200] Report: printers=5 D [03/Sep/2016:12:56:03 +0200] Report: stringpool-string-count=25786 D [03/Sep/2016:12:56:03 +0200] Report: stringpool-alloc-bytes=14216 D [03/Sep/2016:12:56:03 +0200] Report: stringpool-total-bytes=451312 D [03/Sep/2016:12:57:03 +0200] Report: clients=100 D [03/Sep/2016:12:57:03 +0200] Report: jobs=500 D [03/Sep/2016:12:57:03 +0200] Report: jobs-active=0 D [03/Sep/2016:12:57:03 +0200] Report: printers=5 D [03/Sep/2016:12:57:03 +0200] Report: stringpool-string-count=25786 D [03/Sep/2016:12:57:03 +0200] Report: stringpool-alloc-bytes=14216 D [03/Sep/2016:12:57:03 +0200] Report: stringpool-total-bytes=451312 D [03/Sep/2016:12:57:15 +0200] Closing client 553 after 300 seconds of inactivity. D [03/Sep/2016:12:57:15 +0200] [Client 553] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" =========== There is too many connections and the new job can't be accepted, until cups kills some clients as no been active. It seems that the culprit is an application which sends too many requests in the same two seconds. I don't know which application it can be. After one of the connection is freed, the printing can proceed again. It seems that cups gives a client number to requests. Is it an error that it gives different number to each new request? The following with the next job starting: ========== I [03/Sep/2016:12:57:15 +0200] Resuming new connection processing... D [03/Sep/2016:12:57:15 +0200] Closing client 554 after 300 seconds of inactivity. D [03/Sep/2016:12:57:15 +0200] [Client 554] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" D [03/Sep/2016:12:57:15 +0200] Closing client 555 after 300 seconds of inactivity. D [03/Sep/2016:12:57:15 +0200] [Client 555] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" D [03/Sep/2016:12:57:15 +0200] Closing client 556 after 300 seconds of inactivity. D [03/Sep/2016:12:57:15 +0200] [Client 556] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" [...] D [03/Sep/2016:12:57:15 +0200] [Client 575] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" D [03/Sep/2016:12:57:15 +0200] Closing client 576 after 300 seconds of inactivity. D [03/Sep/2016:12:57:15 +0200] [Client 576] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Not busy" D [03/Sep/2016:12:57:15 +0200] [Client 660] Accepted from localhost:60915 (IPv6) D [03/Sep/2016:12:57:15 +0200] [Client 660] Waiting for request. D [03/Sep/2016:12:57:15 +0200] [Client 661] Accepted from localhost (Domain) D [03/Sep/2016:12:57:15 +0200] [Client 661] Waiting for request. D [03/Sep/2016:12:57:15 +0200] [Client 662] Accepted from localhost:60916 (IPv6) D [03/Sep/2016:12:57:15 +0200] [Client 662] Waiting for request. D [03/Sep/2016:12:57:15 +0200] [Client 663] Accepted from localhost (Domain) D [03/Sep/2016:12:57:15 +0200] [Client 663] Waiting for request. D [03/Sep/2016:12:57:15 +0200] [Client 661] POST / HTTP/1.1 D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Not busy" D [03/Sep/2016:12:57:15 +0200] [Client 661] Read: status=200 D [03/Sep/2016:12:57:15 +0200] [Client 661] No authentication data provided. D [03/Sep/2016:12:57:15 +0200] [Client 661] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Active clients" D [03/Sep/2016:12:57:15 +0200] [Client 664] Accepted from localhost:60917 (IPv6) D [03/Sep/2016:12:57:15 +0200] [Client 664] Waiting for request. D [03/Sep/2016:12:57:15 +0200] [Client 665] Accepted from localhost (Domain) D [03/Sep/2016:12:57:15 +0200] [Client 665] Waiting for request. D [03/Sep/2016:12:57:15 +0200] [Client 663] POST / HTTP/1.1 D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Not busy" D [03/Sep/2016:12:57:15 +0200] [Client 663] Read: status=200 D [03/Sep/2016:12:57:15 +0200] [Client 663] No authentication data provided. D [03/Sep/2016:12:57:15 +0200] [Client 663] Closing connection. D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Not busy", busy="Active clients" D [03/Sep/2016:12:57:15 +0200] [Client 666] Accepted from localhost:60918 (IPv6) D [03/Sep/2016:12:57:15 +0200] [Client 666] Waiting for request. D [03/Sep/2016:12:57:15 +0200] [Client 665] POST /printers/Brother-MFC-9330CDW HTTP/1.1 D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Not busy" D [03/Sep/2016:12:57:15 +0200] [Client 665] Read: status=200 D [03/Sep/2016:12:57:15 +0200] [Client 665] No authentication data provided. D [03/Sep/2016:12:57:15 +0200] [Client 665] 1.1 Create-Job 2 D [03/Sep/2016:12:57:15 +0200] Create-Job ipp://localhost:631/printers/Brother-MFC-9330CDW D [03/Sep/2016:12:57:15 +0200] [Job 23] Removing from history. D [03/Sep/2016:12:57:15 +0200] [Job 58] Removing document files. D [03/Sep/2016:12:57:15 +0200] cupsdMarkDirty(---J-) D [03/Sep/2016:12:57:15 +0200] cupsdSetBusyState: newbusy="Active clients and dirty files", busy="Active clients" [...]
The problem is still valid in cauldron.
Just tested in up to date cauldron under VirtualBox. No problem at all, but then again I have never been able to duplicate this issue. Possible differences are that I am using the IPP protocol to send the job to the printer over the local network (KONICA MINOLTA magicolor 4750) and this colour laserjet has an internal postscript interpreter so Cups does not have to rasterise or send PCL to the printer. I believe the default print format for Okular (and KDE print system) is postscript, so Cups does not need to do much.
Both users still have this problem here on Mageia-5, and not only with Okular, as I had the same problem with KMail the other day. Fortunately, 'systemctl restart cups' is an immediate workaround...
Any progress with proper fix?
Today is the first I've tried installing my HP printers in Cauldron. I saw the problem in Mageia 5, but as of a few minutes ago I do not see it when printing from either Gwenview or Okular in Cauldron.
CC: (none) => mageiaVersion: Cauldron => 5
Whiteboard: MGA5TOO => (none)
I confirm that cauldron seems OK now. I launched 2 prints of the same document with Okular. All went fine. Thus, I change it to MGA5 only. Papoteur
CC: (none) => LpSolit
Fair enough - though sad no MGA5 solution. :-(
Could one not just backport cups from Cauldron to maga5 at least to test whether that was where the problem was?
I also experience this problem okular. So I support also the request by w unruh. Please backport the fix from Cauldron.
CC: (none) => olivier.delaune
I am still on the cc list for this bug. I wanted to remove myself, but only the first 5 of 15 addresses are showing. The scrollbar is full length. Is this a Bugzilla problem?
CC: laidlaws => cae
(In reply to Doug Laidlaw from comment #55) > I am still on the cc list for this bug. I wanted to remove myself, but only > the first 5 of 15 addresses are showing. The scrollbar is full length. Is > this a Bugzilla problem? Must be your browser. When I select 'show' cc list, using scroll I can see all in both Chrome-unstable ab opera-beta. At any rate I removed your addy from the cc list.
This bug was only valid in Mageia 5, which is no longer supported, so closing as OLD
Resolution: (none) => OLDStatus: NEW => RESOLVED