Bug 368848 - The second printing takes a while and can be lost
Summary: The second printing takes a while and can be lost
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: printing (show other bugs)
Version: 0.20.3
Platform: Mageia RPMs Linux
: NOR major
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-15 12:45 UTC by Papoteur
Modified: 2018-07-06 16:07 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Papoteur 2016-09-15 12:45:32 UTC
The problem is reproducible.
Open a document with okular.
Print it, or only one page. The page is printed.
Start a second print, without closing the document. Okular hangs until a timeout expire. Sometimes the second printing can be out after the hang term, sometimes not.
By activating the debug, I saw this outputs  when launching two printings of the same document :
okular(24759)/okular (app) Okular::FilePrinter::doPrintFiles: Executing "lpr-cups" with arguments ("-P", "Brother-MFC-9330CDW", "-#1", "-J", "courrier vet.odt", "-o", "media=A4", "-o", "portrait", "-o", "sides=one-sided", "-o", "outputorder=normal", "-o", "Collate=False", "-o", "page-left=10", "-o", "page-top=10", "-o", "page-right=10", "-o", "page-bottom=10", "-o", "fit-to-page", "-r", "/tmp/kde-yves/okularN24759.ps")
okular(24759)/okular (app) Okular::FilePrinter::doPrintFiles: Executing "lpr-cups" with arguments ("-P", "Brother-MFC-9330CDW", "-#1", "-J", "courrier vet.odt", "-o", "media=A4", "-o", "portrait", "-o", "sides=one-sided", "-o", "outputorder=normal", "-o", "Collate=False", "-o", "page-left=10", "-o", "page-top=10", "-o", "page-right=10", "-o", "page-bottom=10", "-o", "fit-to-page", "-r", "/tmp/kde-yves/okularN24759.ps")
lpr-cups: Succès

The second command freezes Okular and didn't success.
The two commands are executing lpr-cups with the same parameters, including the same temp file name. Is there a collision between them?
In the same time, cups debug output said (extracts):
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...

During this time, okular hangs.
After some time:
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.

And the process become unlocked.



Reproducible: Always




Other information here:
https://bugs.mageia.org/show_bug.cgi?id=16330
Comment 1 Papoteur 2018-07-06 16:07:43 UTC
Now solved with newest something