gvfsd-http not closing tcp connections

[Josh Dalziel]

Binary package hint: gvfs

How to recreate the bug...

Run Rhythmbox, and enable the context pane + album art, and lyrics for good measure as well. Close the plugins windows that pops up, click on the new icon next to the Ubuntu One Music store and your new window should show up. The context pane is great for me, as I love to know what I can about the music I listen to. Rhythmbox, through gvfsd-http has now fetched all your cool text from last.fm about your artist, but it does not close the connection. These connections stay in close_wait till you kill the gvfsd-http process.

this happens any time gvfsd-http is used.
netstat -a |grep tcp

tcp 1 0 farva:47729 10x.terra.com.br:www CLOSE_WAIT
tcp 1 0 farva:35961 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 1 0 farva:36086 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 1 0 farva:42357 10x.terra.com.br:www CLOSE_WAIT
tcp 0 0 farva:47836 64.208.5.34:www ESTABLISHED
tcp 1 0 farva:42219 10x.terra.com.br:www CLOSE_WAIT
tcp 1 0 farva:46945 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 1 0 farva:36126 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 1 0 farva:59815 64.208.5.24:www CLOSE_WAIT
tcp 0 0 farva:24800 wabothlp0282996.gs:6776 ESTABLISHED
tcp 1 0 farva:36021 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 0 0 farva:37285 64.208.5.26:www ESTABLISHED
tcp 1 0 farva:33204 64.208.5.34:www CLOSE_WAIT
tcp 1 0 farva:36007 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 1 0 farva:53431 10x.terra.com.br:www CLOSE_WAIT
tcp 1 0 farva:35975 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 1 0 farva:59027 5b.29.78ae.static.t:www CLOSE_WAIT
tcp 1 0 farva:47637 10x.terra.com.br:www CLOSE_WAIT
tcp 1 0 farva:58324 207.114.197.87:www CLOSE_WAIT
tcp 5131 0 farva:42165 10x.terra.com.br:www CLOSE_WAIT

gvfsd-htt 1795 josh 18r IPv4 30730 0t0 TCP farva:54963->10x.terra.com.br:www (CLOSE_WAIT)
gvfsd-htt 1795 josh 19u IPv4 38478 0t0 TCP farva:39645->5b.29.78ae.static.theplanet.com:www (CLOSE_WAIT)
gvfsd-htt 1795 josh 22u IPv4 23139 0t0 TCP farva:39074->5b.29.78ae.static.theplanet.com:www (CLOSE_WAIT)
gvfsd-htt 1795 josh 24u IPv4 19766 0t0 TCP farva:42176->10x.terra.com.br:www (CLOSE_WAIT)
gvfsd-htt 1795 josh 25u sock 0,6 0t0 19650 can't identify protocol
gvfsd-htt 1795 josh 26u IPv4 19607 0t0 TCP farva:35892->5b.29.78ae.static.theplanet.com:www (CLOSE_WAIT)
gvfsd-htt 1795 josh 27u IPv4 20164 0t0 TCP farva:42219->10x.terra.com.br:www (CLOSE_WAIT)
gvfsd-htt 1795 josh 29u IPv4 38494 0t0 TCP farva:51584->10x.terra.com.br:www (CLOSE_WAIT)
gvfsd-htt 1795 josh 30u sock 0,6 0t0 23195 can't identify protocol
gvfsd-htt 1795 josh 31u sock 0,6 0t0 20157 can't identify protocol

I posted a form message about this too
http://ubuntuforums.org/showthread.php?p=10646961#post10646961

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the stable release - Oneiric Ocelot. It would help us greatly if you could test with it so we can work on getting it fixed. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Launchpad Janitor (janitor)]

[Expired for gvfs (Ubuntu) because there has been no activity for 60 days.]

[Paul Bakulich (palbakulich)]

I'd love to see this bug re-opened.

Still happening in Ubuntu 12.04!!

[Josh Dalziel (josh-dalziel)]

Yes this is still a problem... They are too busy screwing up the gnome UI too fix the problem. Its a gnome problem though not Ubuntu, but no one will work on the problem.

[Josh Dalziel (josh-dalziel)]

I changed it to a security vulnerability. Open local ports with no connection on the other end....... Sounds pretty pretty secure to me

[Sebastien Bacher (seb128)]

Hi, you are commenting on a closed bug and should better send the bug to GNOME and stop trolling, comments like "They are too busy screwing up the gnome UI" show that you understand little about what i.e the Ubuntu Desktop Team is doing, the fact that other teams do design work is orthogonal to the fact that other people work on fixing bugs

[Josh Dalziel (josh-dalziel)]

While I understand your frustration, you should take the time to understand that of the user community at large. You are the first 'person' to respond to this tread, and it took "trolling" to do so, and this problem has existed in 4 release's, now going into its 5th. I took the time to file the report all I want to is someone to take the time to help, with out me having to be an ass hat. So how we work together to solve the problem...

[Sebastien Bacher (seb128)]

the issue is simply that this code has no maintainer in Ubuntu (nor in upstream at the moment it seems), working on it would require somebody who has a clue about webdav and the gvfs-http code

[Marc Deslauriers (mdeslaur)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Launchpad Janitor (janitor)]

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

[Serge (sspapilin)]

It involves Firefox connections too, I'm now having several connections to sites I visited in Firefox, like this:

$ netstat -tpW
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 1 0 2a00:f480:4:2a1:f1ff:f3ad:c754:cdfb%862477461:37632 wikipedia-lb.esams.wikimedia.org:http CLOSE_WAIT 4807/gvfsd-http

[Dan Jared (danjaredg)]

This bug is in Ubuntu 12.10, and also, the gvfsd-http process doesn't free memory

[Dan Jared (danjaredg)]

The bug was a patch on versión 1.15.0+ (https://bugzilla.gnome.org/show_bug.cgi?id=639777#c4). Please check that, with this bug the unity previews are inoperable, the server runs out of memory for its use

[Sebastien Bacher (seb128)]

Setting to fix commited since it's fixed upstream in 1.15 apparently, we still should look at fixing the issue in stable series though, the upstream "fix" has been through some refactoring so we can't really backport it as it

[Sebastien Bacher (seb128)]

The corresponding commit, for the record:
http://git.gnome.org/browse/gvfs/commit/?id=cac808508f1fcdb3c9c00cdb36ba6053a1f5dbbb

[Greg W. (mttbrnsmls)]

gvfsd-http stays connected (ESTABLISHED) for long periods of time after I've used VLC to play streaming Youtube videos. This is the case even after I've closed VLC. Plus when lsof finally stops reporting the connection as "established" it will start reporting it as CLOSE_WAIT. And it stays as CLOSE_WAIT for a very long time.

[Filiprino (filiprino)]

I hope this **** is in Ubuntu Raring.

[Sebastien Bacher (seb128)]

Well, you can test and tell us rather than commenting with no content...

[Dan Jared (danjaredg)]

the problem persists on ubuntu 13.04, and this bug generate a memory leak

[Sebastien Bacher (seb128)]

> the problem persists on ubuntu 13.04, and this bug generate a memory leak

can you comment on the upstream bug to say that?

[Dan Jared (danjaredg)]

> can you comment on the upstream bug to say that?

when using gvfsd-http with proxy, set a proxy system an you use unity dash to see photos or another web resource

[Colan Schwartz (colan)]

Not sure if bug #1161317 is a duplicate of this or simply related.

[Filiprino (filiprino)]

You wanted content, here you have.

The problem persists on Ubuntu 13.04:

tcp 1 0 n53sn.local:50570 open.lon2-webproxy-a1.lon.spotify.com:http CLOSE_WAIT 3661/gvfsd-http
tcp 1 0 n53sn.local:42946 mulberry.canonical.com:http CLOSE_WAIT 3661/gvfsd-http
tcp 1 0 n53sn.local:52060 barbadine.canonical.com:http CLOSE_WAIT 3661/gvfsd-http
tcp 1 0 n53sn.local:35037 54.230.62.198:http CLOSE_WAIT 3661/gvfsd-http
tcp 1 0 n53sn.local:52061 barbadine.canonical.com:http CLOSE_WAIT 3661/gvfsd-http

[Øyvind Stegard (oyvindstegard)]

Confirming this bug in 13.04 – I just discovered it five minutes ago. There is a gvfsd-http process that has lots of stale outgoing TCP connections in CLOSE-WAIT-state. All connections have some data in the receive queue and nothing in send.

I did use Rhythmbox a few days ago. Dst-addresses look like Canonical and music store stuff (they do not reverse-resolve, but Google revealed Canonical and 7digital, etc).

tcp 1 0 192.168.10.80:40376 199.27.76.184:80 CLOSE_WAIT 2824/gvfsd-http
tcp 1 0 192.168.10.80:33805 199.27.76.185:80 CLOSE_WAIT 2824/gvfsd-http
tcp 54 0 192.168.10.80:52391 91.189.89.183:443 CLOSE_WAIT 2824/gvfsd-http
tcp 1 0 192.168.10.80:40202 199.27.76.184:80 CLOSE_WAIT 2824/gvfsd-http
tcp 28 0 192.168.10.80:55635 68.232.35.139:443 CLOSE_WAIT 2824/gvfsd-http
[20 more...]

The connections are definitely old, since the source IP is not even my current one.

[Dan Jared (danjaredg)]

Why is invalid?, the logs show the TCP connections on CLOSE WAIT

[HRJ (harshad-rj)]

The outspoken users here seem to be a little too brash. I think rudeness is uncalled for. Please "request" the developers for help gently.

To the developers, please provide more information before closing the bug. This is a reproducible bug and I think it is a security concern in two ways:

1. By default, connections are being established in the background. This could be used to track users on the server side.

2. These connections are then not getting closed!

Even if you don't agree that this is a security issue, this is definitely a valid bug!

Also, I am a little confused about what is called upstream bugs v/s ubuntu bugs. If Ubuntu is maintaining a patchset, should bugs be tracked against Ubuntu or upstream? Secondly, is there a Ubuntu patchset involved here?

Finally, which packages are affected? If I don't want any of these connections until the bug s fixed, which all packages should I remove from my system?

Thanks!

[HRJ (harshad-rj)]

Ok, I looked again at the launchpad headers, and I think I understand the situation better now. Please correct me if I am wrong:

The Ubuntu patchset has been updated and will be part of the next release. Hence it has been marked as "Fix Committed". (If you click the link "Fix Committed" it shows a nice legend of what it means).

The "Invalid" tag is only for the upstream package, because probably the upstream package doesn't have the bug anymore.

For "Precise" and "Quantal" the status is "triaged" which means the fix hasn't been backported yet.

Now a request, can someone apply the patches to Raring atleast? That will not only help a lot of Raring users, it will also help test the patch better.

[Filiprino (filiprino)]

The fix should be backported for 12.04 and 13.04.

Having a connection in CLOSE_WAIT is a potential security risk.

[Filiprino (filiprino)]

I upgraded to 13.10 and I still have this bug. Opened some images on GIMP by giving to it the URL of the photos, and gvfs-http did not close the tcp connections. They remained in CLOSE_WAIT (even after closing GIMP) until I killed the process GVFS.

[itzeme (launchacc)]

Still affecting Ubuntu 12.04.3

Will there be a backport available?

[Luke Carrier (lukecarrier)]

This is still a problem for me running Ubuntu 13.10. I've just discovered it through using Rhythmbox's rb.Loader class to work with Gio (which in turn calls Gio.file_new_for_uri(), file.load_contents_async() and file.load_contents_finish()). Please could somebody shed light on why this issue has been open for so long?

[Jon Lundy (jon-lundy)]

This problem is still present in Ubuntu 14.04.

[Rolf Leggewie (r0lf)]

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

[drm200 (drm200)]

Trusty 14.04 and the problem is still not fixed ....

tcp 1 0 192.168.69.80:47642 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48689 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47602 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47669 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47655 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48748 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48724 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47535 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47570 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47601 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48607 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48753 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48749 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48705 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48669 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47639 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47537 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48643 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48620 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48613 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48734 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47635 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48709 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47540 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48735 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:48691 162.213.33.242:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47679 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp 1 0 192.168.69.80:47577 162.213.33.241:80 CLOSE_WAIT 3824/gvfsd-http off (0.00/0/0)
tcp ...

[HRJ (harshad-rj)]

I can confirm that this is still reproducible in Trusty. I didn't know how to add the Trusty tag, so I have added `trusty-backports` which was offered as a suggestion in the form.

[Mathew Hodson (mhodson)]

According to the upstream bug, this was fixed with https://git.gnome.org/browse/libsoup/commit/?id=96da2df64c9dd8cc52e97ce73e54615d6b520664

I think the fix made it into Vivid, but Trusty and Precise are still affected.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release