GNOME Bugzilla – Bug 563382
Online radio connection remains open after leaving rhythmbox
Last modified: 2011-05-22 13:17:04 UTC
Please describe the problem: i've launched online radios, i noticed that gvfs-http has opened some sockets for the websites as well as rhythmbox. When i stop the playback and close rhythmbox, the sockets of rhythmbox were closed but gvfs-http's were not. They stayed CLOSE_WAIT until i kill the process (three hours after). Is there a way to close all used sockets at leaving (even the gvfs-http ones)? Steps to reproduce: 1. launch rhythmbox 2. launch online radio 3. stop playback and leave rhythmbox Actual results: After checking the sockets with netstat: rhythmbox ones were closed gvfs-http ones remains CLOSE_WAIT until shutdown Expected results: both of rhythmbox and gvfs-http sockets must close Does this happen every time? yes, each time i launch online radio Other information: running Ubuntu 8.10 kernel 2.6.27-9 generic gnome 2.24.1 Rhythmbox 0.11.6 ===================================== Dependencies http://launchpadlibrarian.net/19940103/Dependencies.txt ProcMaps.txt http://launchpadlibrarian.net/19940104/ProcMaps.txt ProcStatus.txt http://launchpadlibrarian.net/19940105/ProcStatus.txt
Architecture: i386 DistroRelease: Ubuntu 8.10 ExecutablePath: /usr/bin/rhythmbox Package: rhythmbox 0.11.6svn20081008-0ubuntu4.2 ProcEnviron: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: rhythmbox Uname: Linux 2.6.27-7-generic i686
there's a libsoup bug here (the fact that it's leaving the connections in CLOSE_WAIT), but is there also a gvfs-http bug? (the fact that it just stays running forever?)
The same thing happends when rhythmbox is downloading podcasts - eventually the gvfs-http process hits the descriptor limit and everything stops working.
*** Bug 564842 has been marked as a duplicate of this bug. ***
Created attachment 128681 [details] [review] Bug 563382 - Define PATH_MAX if not available This fixes the build on Hurd. If anyone ever actually uses Hurd with filenames longer than 4096, they can open a new bug.
Comment on attachment 128681 [details] [review] Bug 563382 - Define PATH_MAX if not available Wrong bug...
Comment on attachment 128681 [details] [review] Bug 563382 - Define PATH_MAX if not available Changing status to get it rid of the unreviewed patches list.
I'm hitting the same problem using Fedora Core 11. I'm using rhythmbox as well, and the only thing I think it's doing is calling amazon to get the album art. gvfsd-htt 2508 mattrose 17u IPv4 280999 0t0 TCP 192.168.1.196:43327->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 18u IPv4 281001 0t0 TCP 192.168.1.196:43328->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 19u IPv4 18910 0t0 TCP 192.168.1.196:47652->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 20u IPv4 69911 0t0 TCP 192.168.1.196:44821->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 21u IPv4 69909 0t0 TCP 192.168.1.196:44820->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 22u IPv4 70067 0t0 TCP 192.168.1.196:36167->192.221.96.126:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 23u IPv4 169020 0t0 TCP 192.168.1.196:46583->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 24u IPv4 171107 0t0 TCP 192.168.1.196:44107->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 25u IPv4 171105 0t0 TCP 192.168.1.196:44106->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 26u IPv4 170719 0t0 TCP 192.168.1.196:52677->192.221.96.126:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 27u IPv4 511136 0t0 TCP 192.168.1.196:35617->ecs.amazonaws.com:http (ESTABLISHED) gvfsd-htt 2508 mattrose 28u IPv4 511138 0t0 TCP 192.168.1.196:35618->ecs.amazonaws.com:http (ESTABLISHED) gvfsd-htt 2508 mattrose 29u IPv4 460618 0t0 TCP 192.168.1.196:37597->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 30u IPv4 460620 0t0 TCP 192.168.1.196:37598->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 31u IPv4 239247 0t0 TCP 192.168.1.196:60838->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 32u IPv4 239249 0t0 TCP 192.168.1.196:60839->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 33u IPv4 239284 0t0 TCP 192.168.1.196:33831->192.221.96.126:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 34u IPv4 452199 0t0 TCP 192.168.1.196:41881->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 35u IPv4 452201 0t0 TCP 192.168.1.196:41882->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 36u IPv4 376888 0t0 TCP 192.168.1.196:41664->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 37u IPv4 314330 0t0 TCP 192.168.1.196:50792->ecs.amazonaws.com:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 38u IPv4 314369 0t0 TCP 192.168.1.196:34641->192.221.96.126:http (CLOSE_WAIT) gvfsd-htt 2508 mattrose 39u IPv4 316247 0t0 TCP 192.168.1.196:42581->ecs.amazonaws.com:http (CLOSE_WAIT)
sorry, a few more details. [root@redman ~]# rpm -q libsoup rhythmbox gvfs libsoup-2.26.3-1.fc11.x86_64 rhythmbox-0.12.3-1.fc11.x86_64 gvfs-1.2.3-12.fc11.x86_64 Sorry I'm not familiar with the internals of these programs, I'm more on the server end of things myself, so I'm not sure where to start digging, but I would bet that gvfs is not shutting down connections when it gets a FIN packet from the other end. I'm not sure why this isn't more widely reported, as it seems like a huge bug to me.
a few more details. I just looked over the close code in gvfs and it seems fine. It might be a problem in that rhythmbox doesn't call it correctly?
It's not just cover art, it's podcasts as well. I have to restart gvfs once or twice a week when it hits the descriptor limit because of all the channels rhythmbox still has open. If it isn't a bug in gvfs then we should presumably transfer this to rhythmhox and ask them to look at it...
the fd leak is fixed in libsoup 2.28. it will still sometimes leave connections in CLOSE_WAIT for a while, but only until the next time it opens a new connection (to anywhere). So if the fact that gvfsd-http never exits is not considered a bug, then this is FIXED.
(In reply to comment #12) > the fd leak is fixed in libsoup 2.28. it will still sometimes leave connections > in CLOSE_WAIT for a while, but only until the next time it opens a new > connection (to anywhere). So if the fact that gvfsd-http never exits is not > considered a bug, then this is FIXED. It is a bug, but a different one than this here, namely bug 509609. I will therefore close this bug here. Thanks everybody.