after certain time printing to cups stops working

[Darko Veberic]

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

[Maximiliano Boscovich (maximiliano-boscovich)]

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.

[Alejandro Azario (alejandroazario)]

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

Thanks in advance

[Christopher M. Peñalver (penalvch)]

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 ?

[Till Kamppeter (till-kamppeter)]

Known upstream bug in LibreOffice:

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

Moving ...

[Darko Veberic (darko-veberic-ung)]

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

[Hu6hzq0zv8rdv031e6g-michael (hu6hzq0zv8rdv031e6g-michael)]

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)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Birgir Haraldsson (biggi-stefna)]

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.

[Helm-volker (helm-volker)]

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

[Franco-violi (franco-violi)]

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.

[Malcolm-whsg (malcolm-whsg)]

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

[Malcolm-whsg (malcolm-whsg)]

Oh, should have said this is 3.6.1 on opensuse 12.2

M

[Nevyn (nevyn)]

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.

[Nevyn (nevyn)]

Looks a lot like Bug 50784

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

[Valentin Höbel (t-valentin)]

@"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

[LISAG (v-hoebel)]

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

[Maximiliano Boscovich (maximiliano-boscovich)]

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.

[Darko Veberic (darko-veberic-ung)]

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)]

... and Malcom was just posting a workaround, not a solution...

[Darko Veberic (darko-veberic-ung)]

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

[Christopher M. Peñalver (penalvch)]

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.

[Darko Veberic (darko-veberic-ung)]

this story is not closed. please read the discussion at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048

[Christopher M. Peñalver (penalvch)]

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.

[Alexpro (alexpro)]

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)

[Francisco javier (ffelix-inode64)]

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

[Francisco javier (ffelix-inode64)]

This is same problem that bug 56344 https://bugs.freedesktop.org/show_bug.cgi?id=56344

[Björn Michaelsen (bjoern-michaelsen)]

closed upstream, needs new report upstream

[Till Kamppeter (till-kamppeter)]

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

[Steve Wilson (stevew)]

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

[xucchini (xucchini)]

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)]

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)]

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)]

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.

[Dean Montgomery (dmonty)]

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

[Owen-genat (owen-genat)]

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?

[Wolfgang Walter (wolfgang-walter)]

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;
+ }
+ }
   }

  /*

[Haenig (haenig)]

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 ;-)

[Haenig (haenig)]

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.

[Owen-genat (owen-genat)]

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.

[Owen-genat (owen-genat)]

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

[Haenig (haenig)]

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

[Björn Michaelsen (bjoern-michaelsen)]

reopening in cups to make sure the additional changes in comment 37 are taken care of.

[Thilo Uttendorfer (t-lo)]

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 ) )
+ { ...

[Launchpad Janitor (janitor)]

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

[Christopher M. Peñalver (penalvch)]

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 .

[Ryan Tandy (rtandy)]

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)]

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

[Marc Deslauriers (mdeslaur)]

Proposed debdiff looks good to me, ACK.

I've uploaded it and subscribed the ubuntu-sru team for processing.

Thanks!

[Brian Murray (brian-murray)]

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.

[Brian Murray (brian-murray)]

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)]

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.

[Marc Deslauriers (mdeslaur)]

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

[Ryan Tandy (rtandy)]

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

[Marc Deslauriers (mdeslaur)]

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!

[Ryan Tandy (rtandy)]

> 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)]

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!

[Ryan Tandy (rtandy)]

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.

[Launchpad Janitor (janitor)]

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

[Colin Watson (cjwatson)]

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)]

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)]

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)]

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.