after certain time printing to cups stops working

Bug #1020048 reported by Darko Veberic on 2012-07-02
108
This bug affects 20 people
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/cupsd.conf :
Timeout 62400

Problem description:

Steps to reproduce:
1. Use a remote cups server to print, no a local one.
2. Set /etc/cups/client.conf to use it remote cups server
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.

I have the same problem, but sometimes this happens before 20 minutes. I also use a remote cups server.

Thanks in advance

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://wiki.ubuntu.com/DebuggingPrintingProblems ?

affects: libreoffice (Ubuntu) → cups (Ubuntu)
Changed in cups (Ubuntu):
status: New → Incomplete
Till Kamppeter (till-kamppeter) wrote :

Known upstream bug in LibreOffice:

https://bugs.freedesktop.org/show_bug.cgi?id=50784

Moving ...

affects: cups (Ubuntu) → libreoffice (Ubuntu)
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed

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/client.conf instead, just as original upstream bug description...

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

I can confirm the bug too.
My solution:
- Look into the file /etc/cups/cupsd.conf
- 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/cups/cups.sock
- Restart cups (ubuntu): restart cups

cat /etc/cups/cupsd.conf
...
...
...
# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock
...
...
...

Launchpad Janitor (janitor) wrote :

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.

Download full text (3.8 KiB)

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/cupsd.conf file. Hope it'll help. (Sorry for my poor english).

LogLevel warn
MaxLogSize 1m
SystemGroup lpadmin
Listen localhost:631
Listen /var/run/cups/cups.sock
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseRemoteProtocols cups
BrowseLocalProtocols
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
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <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-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
    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-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Cancel-Job CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>
<Policy authenticated>
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <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-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CU...

Read more...

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

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/<user>/.cups/client.conf with 'ServerName <someprintserver>'

Since we're using cups on regular basis we are hoping for a solution.

Valentin Höbel (t-valentin) wrote :

@"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-0ubuntu3~ppa1~precise1

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.1\r\nContent-Length: 275\r\nContent-Type: application/ipp\r\nHost: myhost.mydomain.tld\r\nUser-Agent: CUPS/1.5.3\r\nExpect: 100-continue\r\n\r\n", 155, 0, NULL, 0) = 155
27989 18:35:53 sendto(35, "\1\1\0\5\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5de-deE\0\vprinter-uri\0!ipp://localhost:631/printers/lp16B\0\24requesting-user-name\0\6myusernameB\0\10job-name\0\nUnbenannt1I\0\17document-format\0\30app"..., 275, 0, NULL, 0) = 275
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

Also sounds like:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048

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-0ubuntu3~ppa1~precise1

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.1\r\nContent-Length: 275\r\nContent-Type: application/ipp\r\nHost: myhost.mydomain.tld\r\nUser-Agent: CUPS/1.5.3\r\nExpect: 100-continue\r\n\r\n", 155, 0, NULL, 0) = 155
27989 18:35:53 sendto(35, "\1\1\0\5\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5de-deE\0\vprinter-uri\0!ipp://localhost:631/printers/lp16B\0\24requesting-user-name\0\6myusernameB\0\10job-name\0\nUnbenannt1I\0\17document-format\0\30app"..., 275, 0, NULL, 0) = 275
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/cupsd.conf on the print server.

Regards.

             Maximiliano.

Changed in df-libreoffice:
status: Confirmed → Invalid

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?

... 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://wiki.documentfoundation.org/BugReport .

Thank you for your understanding.

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://bugs.freedesktop.org/show_bug.cgi?id=50784#c8 . If you have a bug in LibreOffice, please follow the instructions previously noted.

Changed in df-libreoffice:
status: Confirmed → Invalid

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 :-(

closed upstream, needs new report upstream

no longer affects: df-libreoffice

Linked to the correct bug report, as of comment #21.

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 :

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 :

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.

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.

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://www.cups.org/str.php?L4187

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 :

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/cupsd.conf

# Show shared printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS dnssd
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/client.conf . This will force cups to use /var/run/cups/cups.sock on the client.

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/cups/cups.sock) ...
   =>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://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048/comments/34

Does anyone know if this fixed the LO issue reported here? Perhaps this can be RESOLVED as NOTOURBUG?

The fix in http://www.cups.org/str.php?L4187 is not complete. It misses the case where the server terminates the connection. recv() then does not return with an error but returns 0 (EOF). The last case is missed.

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 @@
       httpClose(cg->http);
       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);
+ cg->http = NULL;
+ }
+ }
   }

  /*

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://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048/comments/33

and subsequently uses the systems default print dialogue the issue disappears (by circumventing ). So for me it is rather IDEEDOURBUG ;-)

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://software.opensuse.org/package/cups

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://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048/comments/37

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 :
Download full text (3.8 KiB)

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.5.3/cups/request.c
===================================================================
--- cups-1.5.3.orig/cups/request.c 2011-09-22 00:09:29.000000000 +0200
+++ cups-1.5.3/cups/request.c 2013-08-27 18:23:35.000000000 +0200
@@ -643,11 +643,13 @@
   }
   else if (http->state != HTTP_WAITING)
   {
- DEBUG_printf(("1cupsSendRequest: Unknown HTTP state (%d), bailing.",
- http->state));
- _cupsSetError(IPP_INTERNAL_ERROR, strerror(EINVAL), 0);
-
- return (HTTP_ERROR);
+ DEBUG_printf(("1cupsSendRequest: Unknown HTTP state (%d), "
+ "reconnecting.", http->state));
+ if (httpReconnect(http))
+ {
+ _cupsSetError(IPP_INTERNAL_ERROR, strerror(EINVAL), 0);
+ return (HTTP_ERROR);
+ }
   }

 #ifdef HAVE_SSL
@@ -1004,6 +1006,26 @@
       httpClose(cg->http);
       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 ) )
+ { ...

Read more...

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cups - 1.7.0~rc1-0ubuntu2

---------------
cups (1.7.0~rc1-0ubuntu2) saucy; urgency=low

  * debian/patches/handle-server-terminating-connection.patch: Fix the handling
    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://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048/comments/45 .

description: updated
Changed in libreoffice (Ubuntu):
status: Confirmed → Invalid
Changed in df-libreoffice:
importance: Medium → Undecided
status: New → Invalid
Ryan Tandy (rtandy) wrote :

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://www.cups.org/strfiles.php/3164/str4187.patch from upstream STR#4817 (CUPS 1.6.2, released in raring) plus improvement from upstream git 80360a5e (CUPS 1.6.4, released in saucy), backported to precise.

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 :

opened a nomination for precise. On a chat on #ubuntu-bugs, the author asked for the nomination. I agree with it, so there.

Ryan Tandy (rtandy) on 2014-03-25
Changed in libreoffice (Ubuntu Precise):
status: New → Invalid
tags: added: patch
Changed in cups (Ubuntu Precise):
status: New → Confirmed
Ryan Tandy (rtandy) on 2014-03-25
description: updated
Marc Deslauriers (mdeslaur) wrote :

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 :

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://launchpad.net/ubuntu/+source/cups/1.5.3-0ubuntu8.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Ryan Tandy (rtandy) wrote :

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 :

Unfortunately, the package in -proposed got superseded by a security update. A new debdiff and upload must be done.

Ryan Tandy (rtandy) wrote :

Rebased debdiff including the security update. Thanks for the heads up about that.

tags: removed: verification-done
Marc Deslauriers (mdeslaur) wrote :

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 :

> 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 :

Hello Darko, or anyone else affected,

Accepted cups into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/cups/1.5.3-0ubuntu8.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in cups (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Ryan Tandy (rtandy) wrote :

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 :

This bug was fixed in the package cups - 1.5.3-0ubuntu8.3

---------------
cups (1.5.3-0ubuntu8.3) precise; urgency=low

  * debian/patches/handle-server-terminating-connection.patch: Fix the
    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 :

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/client.conf, but instead a normal full Ubuntu 16.04 installation + all released updates.

Joshua Geake (joshgeake) wrote :

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.

Raúl Vidal (raulvior-bcn) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.