after certain time printing to cups stops working
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| LibreOffice |
Invalid
|
Undecided
|
Unassigned | |
| cups (Ubuntu) |
High
|
Unassigned | ||
| Precise |
Undecided
|
Unassigned | ||
| libreoffice (Ubuntu) |
High
|
Unassigned | ||
| Precise |
Undecided
|
Unassigned |
Bug Description
SRU justification:
[Impact]
* When the CUPS client connects to a remote cupsd over TCP, the server
closes an idle connection after 5 minutes and the client does not reconnect.
* LibreOffice is affected because it keeps a CUPS connection open. The
effect is that printing to a remote cupsd is no longer possible after
LibreOffice has been open for 5 minutes.
[Test Case]
* This can be reproduced on a desktop system. You don't need a separate
CUPS server.
* You need at least one print queue in CUPS. If you don't have a
printer, install "cups-pdf".
* Optional, configure CUPS with a shorter timeout for testing:
sudo cupsctl Timeout=30 # seconds
sudo restart cups
* Configure the CUPS client to use a TCP socket:
mkdir ~/.cups
echo ServerName 127.0.0.1 > ~/.cups/client.conf
* Open LibreOffice. Press Ctrl-P to open the Print dialog. Press Esc to
dismiss the dialog. Wait long enough for the timout to elapse (5
minutes by default, or as per the Timeout setting).
* Try to print. With cups in precise, the job simply vanishes and is
never seen by the server. With the proposed patch, printing works
normally.
[Regression Potential]
* The patch changes a library linked by many programs. An incorrect
change might result in those programs misbehaving or crashing.
* The patch is minimal, only adding a branch to handle a case that was
previously not handled. The behaviour in other cases should be
unchanged.
[Other Info]
* A workaround is to set the cupsd Timeout to a high value such as 8
hours. This works on a server with few users, but on a busy server
more and more connections are opened and eventually cupsd isn't able
to accept new clients.
Original description:
== Problem ==
In our institution we are running only printers through a cups server. while freshly opened document prints well, after some time (few minutes) clicking "print file directly" and menu item "print" do not work any more. after close and open again, thing prints correctly. i have checked what exactly is going on in such cases and logs on the cups server don't show any submissions and/or errors so that the thing is obviously stopped at the level of libreoffice.
== Analysis ==
LibreOffice loses it's TCP connection to CUPS after exactly 5 minutes of inactivity and does not manage to reconnect. To reproduce: print something (to a real printer or cups-pdf), wait 6 minutes not printing anything, and print again. Then, nothing is printed. You can watch the TCP connection using
netstat -tpn | grep soffice
While it's working, it looks like this:
tcp 0 0 127.0.0.1:48810 127.0.0.1:631 ESTABLISHED 13976/soffice.bin
After 5 minutes, that connection is gone permanently.
WORKAROUND: To set the timeout to 24 hours add this line to the top of /etc/cups/
Timeout 62400
I have the same problem, but sometimes this happens before 20 minutes. I also use a remote cups server.
Thanks in advance
Darko Veberic (darko-veberic-ung) wrote : | #1 |
Christopher M. Peñalver (penalvch) wrote : | #2 |
Darko Veberic, thank you for reporting this and helping make Ubuntu better. Regarding your comments:
>"i have checked what exactly is going on in such cases and logs on the cups server don't show any submissions and/or errors so that the thing is obviously stopped at the level of libreoffice."
Unfortunately, it is not obvious because no logs are attached to this report. Hence, could you please provide the information following https:/
affects: | libreoffice (Ubuntu) → cups (Ubuntu) |
Changed in cups (Ubuntu): | |
status: | New → Incomplete |
Changed in df-libreoffice: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Darko Veberic (darko-veberic-ung) wrote : | #6 |
ok, i will try to look deeper into the logs... but as i said before, the remote cups server does not get any jobs submitted. i also forgot to tell that we disable local cups daemons and write remote server name in the /etc/cups/
another detail is that i can actually open a document file and leave it open even for long time and the first print attempt will work correctly. if only after that first printing, i wait some time, the second printing does not work, neither from the "print directly" icon, nor from the file menu (but in contrast to the upstream bug report i can still see a list of all our institutional printers). i hope this clarifies the situation a bit...
Changed in libreoffice (Ubuntu): | |
status: | Incomplete → New |
|
#8 |
I can confirm the bug too.
My solution:
- Look into the file /etc/cups/
- The following entry is listed: Listen 127.0.0.1:631
- Edit this entry from 127.0.0.1 -> localhost
- Add this line: Listen /var/run/
- Restart cups (ubuntu): restart cups
cat /etc/cups/
...
...
...
# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/
...
...
...
Launchpad Janitor (janitor) wrote : | #7 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in libreoffice (Ubuntu): | |
status: | New → Confirmed |
I confirm this problem as well.
Had to move 200 Ubuntu machines from a centralized cups to locally configured setup by distributing cups config via puppet.
Would love to see a solution to this soon.
We got a similar problem. When you start libreoffice, printing work, after a short time, around 5 min, you can't print from libreoffice any more.
System kubuntu 12.04 x86 with kde 4.9.
We're printing over remote cups (cups.client), but we a local cups server the same problem appears too.
here is my /etc/cups/
LogLevel warn
MaxLogSize 1m
SystemGroup lpadmin
Listen localhost:631
Listen /var/run/
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseRemotePro
BrowseLocalProt
DefaultAuthType Basic
WebInterface Yes
<Location />
Order allow,deny
</Location>
<Location /admin>
Order allow,deny
</Location>
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
Order allow,deny
</Location>
<Policy default>
JobPrivateAccess default
JobPrivateValues default
SubscriptionP
SubscriptionP
<Limit Create-Job Print-Job Print-URI Validate-Job>
Order deny,allow
</Limit>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Add-
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Cancel-Job CUPS-Authentica
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit All>
Order deny,allow
</Limit>
</Policy>
<Policy authenticated>
JobPrivateAccess default
JobPrivateValues default
SubscriptionP
SubscriptionP
<Limit Create-Job Print-Job Print-URI Validate-Job>
AuthType Default
Order deny,allow
</Limit>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Add-
On Linux system, cups has a timeout of 300 seconds by default. When you print from OpenOffice the first time, everything is ok. If you wait more then 300 seconds and then try to print again, nothing happen. When nothing happen, go into the printer dialog and you will get an empty list. Increasing at infinity the cups timeout, you have no problem but this cannot be the solution.
If you drop the cups option using the printer admin dialog, everything is fine.
I'll bet you it's not 'around five minutes' it's exactly five minutes.
That's the default client time out for connections to the cups server.
We have a nasty work around for this. Near the top of the
cupsd.conf and add TIMEOUT 'somebignumber' I have set mine
to 5400 which is 90 mins. As this is a school and everything runs
in 1 hour chunks that is fine. The downside is you may have a
lot of connections hanging around. I would guess that if you are
in a company where people work 9-5 that number would have to be
very big ( but smaller than the night in seconds so that any
dead connections can time out over night )
90 mins with 400 workstations to one CUPS server doesn't seem to
stress the print server particularly and it works here ( YMMV )
We would really like this fixed as well
regards
M
Oh, should have said this is 3.6.1 on opensuse 12.2
M
|
#25 |
I've got a similar problem also.
libreoffice 3.5.4 kubuntu 12.04 i386.
My libreoffice loses cups connection after around 5 min. All printers are shown, but doesn't print including cups-pdf printer.
I supposed the printers are shown through /home/<
Since we're using cups on regular basis we are hoping for a solution.
Valentin Höbel (t-valentin) wrote : | #13 |
@"Malcolm-whsg (malcolm-whsg) wrote on 2012-10-24:"
We can confirm this issue and also that the workaround with a higher timeout value for CUPS works.
Our details:
Ubuntu 12.04 64 Bit
3.2.0-33-generic #52-Ubuntu SMP
Libre Office 3.6.0~rc4-
We performed a debugging session yesterday and observed that Libre Office looses the connection to the CUPS server within 5 minutes:
- tshark on the CUPS server, observing the connection close:
353.291104 192.168.1.1 -> 192.168.1.115 IPP 245 IPP response
353.291352 192.168.1.115 -> 192.168.1.1 TCP 66 52363 > 631 [ACK] Seq=7064 Ack=45384 Win=42272 Len=0 TSval=8393025 TSecr=8563624
[no further packages]
384.142218 192.168.1.1 -> 192.168.1.115 TCP 66 631 > 52363 [FIN, ACK] Seq=45384 Ack=7064 Win=33792 Len=0 TSval=8571337 TSecr=8393025
384.178858 192.168.1.115 -> 192.168.1.1 TCP 66 52363 > 631 [ACK] Seq=7064 Ack=45385 Win=42272 Len=0 TSval=8400747 TSecr=8571337
- Other actions of Libre Office will be answered with a connection reset:
406.177739 192.168.1.115 -> 192.168.1.1 TCP 221 [TCP segment of a reassembled PDU]
406.177767 192.168.1.1 -> 192.168.1.115 TCP 54 631 > 52363 [RST] Seq=45385 Win=0 Len=0
406.177840 192.168.1.115 -> 192.168.1.1 IPP 341 IPP request
406.177851 192.168.1.1 -> 192.168.1.115 TCP 54 631 > 52363 [RST] Seq=45385 Win=0 Len=0
- From this point of time on, Libre Office "knows" that there is no connection with the CUPS server and doesn't open a new one.
- stracing shows the second printing attempt:
27989 18:35:53 sendto(35, "POST /printers/lp16 HTTP/1.
27989 18:35:53 sendto(35, "\1\1\0\
27989 18:35:53 poll([{fd=35, events=POLLIN}], 1, 1000) = 1 ([{fd=35, revents=POLLIN}])
27989 18:35:53 poll([{fd=35, events=POLLIN}], 1, 60000) = 1 ([{fd=35, revents=POLLIN}])
27989 18:35:53 recvfrom(35, "", 2048, 0, NULL, NULL) = 0
|
#27 |
Also sounds like:
https:/
We can confirm this issue and also that the workaround with a higher timeout value for CUPS works.
Our details:
Ubuntu 12.04 64 Bit
3.2.0-33-generic #52-Ubuntu SMP
Libre Office 3.6.0~rc4-
We performed a debugging session yesterday and observed that Libre Office looses the connection to the CUPS server within 5 minutes:
- tshark on the CUPS server, observing the connection close:
353.291104 192.168.1.1 -> 192.168.1.115 IPP 245 IPP response
353.291352 192.168.1.115 -> 192.168.1.1 TCP 66 52363 > 631 [ACK] Seq=7064 Ack=45384 Win=42272 Len=0 TSval=8393025 TSecr=8563624
[no further packages]
384.142218 192.168.1.1 -> 192.168.1.115 TCP 66 631 > 52363 [FIN, ACK] Seq=45384 Ack=7064 Win=33792 Len=0 TSval=8571337 TSecr=8393025
384.178858 192.168.1.115 -> 192.168.1.1 TCP 66 52363 > 631 [ACK] Seq=7064 Ack=45385 Win=42272 Len=0 TSval=8400747 TSecr=8571337
- Other actions of Libre Office will be answered with a connection reset:
406.177739 192.168.1.115 -> 192.168.1.1 TCP 221 [TCP segment of a reassembled PDU]
406.177767 192.168.1.1 -> 192.168.1.115 TCP 54 631 > 52363 [RST] Seq=45385 Win=0 Len=0
406.177840 192.168.1.115 -> 192.168.1.1 IPP 341 IPP request
406.177851 192.168.1.1 -> 192.168.1.115 TCP 54 631 > 52363 [RST] Seq=45385 Win=0 Len=0
- From this point of time on, Libre Office "knows" that there is no connection with the CUPS server and doesn't open a new one.
- stracing shows the second printing attempt:
27989 18:35:53 sendto(35, "POST /printers/lp16 HTTP/1.
27989 18:35:53 sendto(35, "\1\1\0\
27989 18:35:53 poll([{fd=35, events=POLLIN}], 1, 1000) = 1 ([{fd=35, revents=POLLIN}])
27989 18:35:53 poll([{fd=35, events=POLLIN}], 1, 60000) = 1 ([{fd=35, revents=POLLIN}])
27989 18:35:53 recvfrom(35, "", 2048, 0, NULL, NULL) = 0
Malcom was right, it was a problem related with cupsd timeout.
I fixed it setting "TimeOut 7200" in the /etc/cups/
Regards.
Changed in df-libreoffice: | |
status: | Confirmed → Invalid |
Darko Veberic (darko-veberic-ung) wrote : | #15 |
i absolutely disagree with the change to "invalid". why would you do that? show me any other program that has "print" menu which stops working after 5 minutes? this is insane.
if the connection is closed by cups due to timeout, libre should simply reopen it. this is the real solution.
let me repeat what's going on: i fire up libre on my draft. i print the draft on my cups printer and i start correcting the document. let's say my corrections take more time to fix than the cups timeout. when i am finished with fixes, i want to print out the final version of the document. what happens? nothing. no error message, nothing. nada. i try print preview, nothing. i try "print direct" button, nothing. this is a clear libre bug and has nothing to do with cups having some default timeout setting. the only way i can get the document printed again is to save the document, close libre, reopen the doc and print again. this time it'll work, but if i want to print another copy, i better do it within the 5 min. otherwise, again nothing happens and what's worse, nothing happens without any warning or error message...
can you reconsider your "invalid" decision?
Darko Veberic (darko-veberic-ung) wrote : | #16 |
... and Malcom was just posting a workaround, not a solution...
sorry, but this is a workaround and not a solution. i don't think it is wise to increase cups connection timeouts, especially if you run cups server for a large institution with a lot of printers and a lot of clients...
from the description of the bug and discussion here it is clear this is a libre bug which can not be fixed by this workaround. you just made the time after which libre fails to print larger. this is not the right solution...
Mal, as Maximiliano Boscovich is the original reporter, if he finds this to not be a bug for him and his infrastructure, and marks it RESOLVED NOTABUG, that's up to him.
However, if you are having a bug in LibreOffice, you are welcome to do so following the instructions verbatim at http://
Thank you for your understanding.
this story is not closed. please read the discussion at https:/
Changed in df-libreoffice: | |
status: | Invalid → Confirmed |
Changed in libreoffice (Ubuntu): | |
importance: | Undecided → High |
Darko, please do not reopen this report as you are not the original reporter, and this bug report is not about your problem. For more on this, please see https:/
Changed in df-libreoffice: | |
status: | Confirmed → Invalid |
|
#28 |
Created attachment 71432
Force reconnection to CUPS server on print failure
I've got the same bug when printing stops after 5 mins.
Attached patch solves this problem for LibreOffice by dropping old
connection and retrying on print error.
Closing old connection is done with cupsSetServer(NULL)
I have Libreoffice 3.6.4.3 in gentoo and after 5 minuts stop printing.. my clients in schools same problem.
Add TimeOut 9000 in cupsd.conf solves half :-(
This is same problem that bug 56344 https:/
closed upstream, needs new report upstream
no longer affects: | df-libreoffice |
Till Kamppeter (till-kamppeter) wrote : | #23 |
Linked to the correct bug report, as of comment #21.
|
#30 |
Any news of when this might be fixed? Increasing the CUPS timeout apparently caused problems with Acrobat Reader so that's not an option for us. That leaves me with telling the users that, if they want to print, they need to either print within five minutes of opening LibreOffice or restart LibreOffice. Not too good... :-)
Thanks!
Steve
Changed in df-libreoffice: | |
importance: | Unknown → Medium |
status: | Unknown → New |
xucchini (xucchini) wrote : | #31 |
I am experiencing this problem on over a hundred of Ubuntu 12.04.2 desktops with cups and libreoffice installed (fully up to date).
I'll try upping the cups timeout for the time being.
xucchini (xucchini) wrote : | #32 |
But just to be clear, I don't want to have cups keeping a bunch of client connections open for a week.
I believe this is still an important problem which causes a lot of negative experiences with ubuntu and libreoffice.
Till Kamppeter (till-kamppeter) wrote : | #33 |
There is another workaround which is probably more reliable and suitable for any duration of LibreOffice session: Switching LibreOffice to the standard GTK print dialog (the dialog used by Evince, Firefox, GEdit, and many other GNOME/GTK apps). You will loose the embedded preview in the print dialog but otherwise printing works and you have one printing UI for most apps.
Proceed as foilows:
- Open LibreOffice
- In the main menu (top bar) choose "Tools", then "Options".
- In the pop-up dialog click "General" in the "LibreOffice" section on the left.
- On the right, near the bottom, mark "Enable experimental (unstable) features".
- Under "Print dialog" unmark "Use LibreOffice dialogs".
- Click "OK".
- Return the timeout values in the CUPS configuration to their original (default) values (if you had changed them).
From now on, whenever you want to print out of LibreOffice you will get the standard print dialog and not LibreOffice's own dialog. Please check, especially on longer sessions or when leaving LibreOffice open over night, whether always the list of available printers appears correctly in the dialog and whether you can print.
Till Kamppeter (till-kamppeter) wrote : | #34 |
CUPS 1.6.2 got released on Monday and I have packaged it for Raring.
It seems that exactly this problem was addressed in this version of CUPS. See
http://
So this should be fixed now in Raring. Please test by undoing the workaround from comment #33 and updating your Raring system so that you get the new CUPS. If this helps please mark the LibreOffice tasks invalid.
Changed in cups (Ubuntu): | |
importance: | Undecided → High |
status: | New → Fix Released |
Dean Montgomery (dmonty) wrote : | #35 |
We run linux clients that connect to a central print server. I found this works:
1) Install cups server on the clients.
2) On clients turn on "Show printers shared by other systems" in web interface or in /etc/cups/
# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProt
BrowseAddress @LOCAL
BrowseAddress server:631
# *** NOTE I've added an entry that points directly to our main cups server - to speed up discovery.
3) On clients add a "BrowseAddress server:631" that points directly to your cups server. Change "server" to addres of your cups server. ( see above )
4) On clients comment out all entries in /etc/cups/
Generally works because libreoffice doesn't communicate over TCP:631, rather directly to the local socket and the client<=>server communication is done via cupsd<=>cupsd:
Client Libreoffice ...
=>local-cups(with browsing on listening on /var/un/
=>server:631 browsing cups ...
=>printer.
It uses a bit more RAM on the client to run the cups server but RAM is not as much of an issue these days.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1071 0.0 0.2 11164 3816 ? Ss 10:45 0:00 /usr/sbin/cupsd -F
Is this still an issue? As pointed out up thread it appears to be the same one as reported in bug #50784 and over on Ubuntu Launchpad. The Launchpad bug appears to indicate that CUPS v1.6.2 (2013-03-18) included a patch that specifically addressed this problem:
https:/
Does anyone know if this fixed the LO issue reported here? Perhaps this can be RESOLVED as NOTOURBUG?
The fix in http://
Here is a modified patch (to apply instead that one of L4187) which solves the issue:
--- ../request.c.orig 2013-04-22 13:48:31.409721696 +0200
+++ cups/request.c 2013-04-22 13:47:15.261963227 +0200
@@ -1004,6 +1004,26 @@
cg->http = NULL;
}
+ else
+ {
+ /*
+ * Same server, see if the connection is still established...
+ */
+
+ char ch; /* Connection check byte */
+ int n;
+
+ if ( (n = recv(cg->http->fd, &ch, 1, MSG_PEEK | MSG_DONTWAIT) == 0) ||
+ ( n < 0 && errno != EWOULDBLOCK ) )
+ {
+ /*
+ * Nope, close the connection...
+ */
+
+ httpClose(
+ cg->http = NULL;
+ }
+ }
}
/*
|
#38 |
For me (libreoffice 3.6.3.2.4 (openSuSE 12.3) it still is a problem.
For which version one could assume the patch from comment 4 beeing included?
This "... Perhaps this can be RESOLVED as NOTOURBUG? ... "
from comment 7 I can _NOT_ second, because if one follows
https:/
and subsequently uses the systems default print dialogue the issue disappears (by circumventing ). So for me it is rather IDEEDOURBUG ;-)
|
#39 |
After installing the latest (from openSuSE build service) version 4.0.3.3.5 I can confitm the persistance of the bug for this version too.
In response to comment #8 and comment #9, which version of CUPS are you running? According to this link OpenSUSE 12.3 include CUPS v1.5.4:
http://
My comment (and those of others) was a suggestion that CUPS v1.6.2 fixes the issue. Does the build service version of OpenSUSE include the newer version of CUPS? If the problem persists with CUPS v1.6.2+ then I think we need to change the bug status from UNCONFIRMED to NEW.
Sorry for the noise, it appears that the original fix to CUPS is in need of a second patch according to this comment on 2013-07-18:
https:/
|
#42 |
The "solution" to not use libreoffices print dialogue is rather no solution too because then the behaviour is much more annoying because when simply wanting to open the print dialogue via 'file' => 'print' (and the timeout has already hit) LO crashes and the open document gets printed without any possibility to prevent it or influence the settings. :-(
reopening in cups to make sure the additional changes in comment 37 are taken care of.
Changed in cups (Ubuntu): | |
status: | Fix Released → Incomplete |
Thilo Uttendorfer (t-lo) wrote : | #44 |
After reading comment #41 and compare the precise version of cups with upstream HEAD, I was able to (re-) build the prceise package with the following patch:
Index: cups-1.
=======
--- cups-1.
+++ cups-1.
@@ -643,11 +643,13 @@
}
else if (http->state != HTTP_WAITING)
{
- DEBUG_printf(
- http->state));
- _cupsSetError(
-
- return (HTTP_ERROR);
+ DEBUG_printf(
+ "reconnecting.", http->state));
+ if (httpReconnect(
+ {
+ _cupsSetError(
+ return (HTTP_ERROR);
+ }
}
#ifdef HAVE_SSL
@@ -1004,6 +1006,26 @@
cg->http = NULL;
}
+ else
+ {
+ /*
+ * Same server, see if the connection is still established...
+ */
+
+ char ch; /* Connection check byte */
+ int n;
+
+ if ( (n = recv(cg->http->fd, &ch, 1, MSG_PEEK | MSG_DONTWAIT) == 0) ||
+ ( n < 0 && errno != EWOULDBLOCK ) )
+ { ...
Launchpad Janitor (janitor) wrote : | #45 |
This bug was fixed in the package cups - 1.7.0~rc1-0ubuntu2
---------------
cups (1.7.0~
* debian/
of a connection terminated by the server (LP: #1020048, comment #37 and
#44).
-- Till Kamppeter <email address hidden> Thu, 5 Sep 2013 22:46:01 +0200
Changed in cups (Ubuntu): | |
status: | Incomplete → Fix Released |
description: | updated |
Closing libreoffice (Ubuntu) task as the problem and fix was identified in cups (Ubuntu), as previously addressed in https:/
description: | updated |
Changed in libreoffice (Ubuntu): | |
status: | Confirmed → Invalid |
Changed in df-libreoffice: | |
importance: | Medium → Undecided |
status: | New → Invalid |
Ryan Tandy (rtandy) wrote : | #47 |
This still affects cups in precise. I've asked in #ubuntu-bugs for a precise task to be added, but in the meantime, here's a debdiff.
Patch is based on http://
I've had users at several sites running this patch in production for the last 3 weeks, with no regressions reported.
C de-Avillez (hggdh2) wrote : | #48 |
opened a nomination for precise. On a chat on #ubuntu-bugs, the author asked for the nomination. I agree with it, so there.
Changed in libreoffice (Ubuntu Precise): | |
status: | New → Invalid |
tags: | added: patch |
Changed in cups (Ubuntu Precise): | |
status: | New → Confirmed |
description: | updated |
Marc Deslauriers (mdeslaur) wrote : | #49 |
Proposed debdiff looks good to me, ACK.
I've uploaded it and subscribed the ubuntu-sru team for processing.
Thanks!
Changed in cups (Ubuntu Precise): | |
status: | Confirmed → In Progress |
Brian Murray (brian-murray) wrote : | #50 |
Given that 1.5.3-0ubuntu8 already exists in -updates for proposed, its unnecessary to add .1 rather ubuntu9 could have been used. Regardless, I'll approve the upload in -proposed.
Changed in cups (Ubuntu Precise): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed |
Hello Darko, or anyone else affected,
Accepted cups into precise-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
Ryan Tandy (rtandy) wrote : | #52 |
With cups 1.5.3-0ubuntu8 from precise, when I configure cups-client to use a TCP connection, print a LibreOffice document, and wait 5 minutes, printing is no longer possible after cupsd drops the idle connection.
With cups 1.5.3-0ubuntu8.1 from precise-proposed and the same cups-client configuration, when I print a LibreOffice document and wait 5 minutes, printing still works.
Marking verified.
tags: |
added: verification-done removed: verification-needed |
Marc Deslauriers (mdeslaur) wrote : | #53 |
Unfortunately, the package in -proposed got superseded by a security update. A new debdiff and upload must be done.
Ryan Tandy (rtandy) wrote : | #54 |
Rebased debdiff including the security update. Thanks for the heads up about that.
tags: | removed: verification-done |
Marc Deslauriers (mdeslaur) wrote : | #55 |
Proposed debdiff looks good to me, ACK.
I've uploaded it with a slightly modified version number for processing by the ubuntu-sru team.
Thanks!
Changed in cups (Ubuntu Precise): | |
status: | Fix Committed → In Progress |
Ryan Tandy (rtandy) wrote : | #56 |
> I've uploaded it with a slightly modified version number for processing by the ubuntu-sru team.
haha, I called it -ubuntu9 this time around because of bdmurray's comment (#50) :)
all good, thanks for uploading Marc!
Brian Murray (brian-murray) wrote : | #57 |
Hello Darko, or anyone else affected,
Accepted cups into precise-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
Changed in cups (Ubuntu Precise): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed |
Ryan Tandy (rtandy) wrote : | #58 |
With cups 1.5.3-0ubuntu8.2 from precise-updates, when I configure cups-client to use a TCP connection, print a LibreOffice document, and wait 5 minutes, printing is no longer possible after cupsd drops the idle connection.
With cups 1.5.3-0ubuntu8.3 from precise-proposed and the same cups-client configuration, when I print a LibreOffice document and wait 5 minutes, printing still works.
Marking verified.
tags: |
added: verification-done removed: verification-needed |
Launchpad Janitor (janitor) wrote : | #59 |
This bug was fixed in the package cups - 1.5.3-0ubuntu8.3
---------------
cups (1.5.3-0ubuntu8.3) precise; urgency=low
* debian/
handling of a connection terminated by the server (LP: #1020048)
-- Ryan Tandy <email address hidden> Thu, 24 Apr 2014 09:17:07 -0700
Changed in cups (Ubuntu Precise): | |
status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for cups has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.
Marc Kolly (makuser) wrote : | #61 |
How is it possible I see the exact same issue with LO (1:5.1.4-0ubuntu1) and cups (2.1.3-4) on Ubuntu 16.04 with a central Debian cups server (1.7.5-11+deb8u1)?
I'm not using the /etc/cups/
Joshua Geake (joshgeake) wrote : | #62 |
I can confirm that this has started happening again on cups 2.1.3 and Ubuntu Server 16.04. Clients that attempt to connect to the server on port 631 (even using telnet) just get their connection refused. It's like cups closes all connections after 5 minutes of inactivity and won't reopen them again. I think it's even happening on the admin page.
ed20900 (ed20900) wrote : | #63 |
I have to confirm this bug. 300 seconds timeout. CUPS does not reopen connections again. Notifiers are shutdown.
The workaround is to enable the web interface. But this should not be necessary. CUPS should work without the web interface, as that is the default behaviour defined by upstream.
Problem description:
Steps to reproduce: client. conf to use it remote cups server
1. Use a remote cups server to print, no a local one.
2. Set /etc/cups/
3. Open writer or calc.
4. Open a document.
5. Go to File -> Print, and you'll see the printers.
6. Keep open libreoffice for 20 minutes.
7. Go to File -> Print, and all printers disappears.
8. Close libreoffice.
9. Start libreoffice again, and go to File -> Print, and you'll see the printers ok.
Current behavior:
The printers disappears when you keep open libreoffice for 20 min. If you close a re-open it, the printers appears again.
I think the problem is related with the fact of libreoffice open a connection with the cups server when it's starts, and its connections is closed a minutes later (i don't know why). Its seem like a libreoffice don't detect this connection lost.
May be libreoffice should open the conection with the cups server when the user open the print dialog, and not when its start.
Platform
Kubuntu 12.04, in a LTSP-Cluster Infraestructure.
PD: Sorry for my english.