gvfsd-http not closing tcp connections

Bug #760344 reported by Josh Dalziel on 2011-04-13
This bug affects 72 people
Affects Status Importance Assigned to Milestone
Fix Released
libsoup (Ubuntu)

Bug Description

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 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 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 ESTABLISHED
tcp 1 0 farva:33204 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 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

Pedro Villavicencio (pedro) wrote :

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.

Changed in gvfs (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

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

Changed in gvfs (Ubuntu):
status: Incomplete → Expired
Paul Bakulich (palbakulich) wrote :

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

Still happening in Ubuntu 12.04!!

Josh Dalziel (josh-dalziel) wrote :

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.

security vulnerability: no → yes
Josh Dalziel (josh-dalziel) wrote :

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

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

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

Changed in gvfs (Ubuntu):
status: Expired → Confirmed
status: Confirmed → New
Sebastien Bacher (seb128) wrote :

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

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.

security vulnerability: yes → no
security vulnerability: yes → no
Launchpad Janitor (janitor) wrote :

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

Changed in gvfs (Ubuntu):
status: New → Confirmed
Sergey Papilin (sspapilin) wrote :

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

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

Dan Jared (danjaredg) wrote :

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

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

Changed in gvfs (Ubuntu):
status: Confirmed → Fix Committed
importance: Low → High
Changed in gvfs (Ubuntu Precise):
importance: Undecided → High
Changed in gvfs (Ubuntu Quantal):
importance: Undecided → High
Changed in gvfs (Ubuntu Precise):
status: New → Triaged
Changed in gvfs (Ubuntu Quantal):
status: New → Triaged
Greg W. (mttbrnsmls) wrote :

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

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

Sebastien Bacher (seb128) wrote :

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

Dan Jared (danjaredg) wrote :

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

Sebastien Bacher (seb128) wrote :

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

> 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

Changed in gvfs:
importance: Unknown → Medium
status: Unknown → Confirmed
Colan Schwartz (colan) wrote :

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

Filiprino (filiprino) wrote :

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 CLOSE_WAIT 3661/gvfsd-http
tcp 1 0 n53sn.local:52061 barbadine.canonical.com:http CLOSE_WAIT 3661/gvfsd-http

Øyvind Stegard (oyvinst) wrote :

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 CLOSE_WAIT 2824/gvfsd-http
tcp 1 0 CLOSE_WAIT 2824/gvfsd-http
tcp 54 0 CLOSE_WAIT 2824/gvfsd-http
tcp 1 0 CLOSE_WAIT 2824/gvfsd-http
tcp 28 0 CLOSE_WAIT 2824/gvfsd-http
[20 more...]

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

Changed in gvfs:
status: Confirmed → Invalid
Dan Jared (danjaredg) wrote :

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

HRJ (harshad-rj) wrote :

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?


HRJ (harshad-rj) wrote :

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

The fix should be backported for 12.04 and 13.04.

Having a connection in CLOSE_WAIT is a potential security risk.

Filiprino (filiprino) wrote :

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.

Martin Pitt (pitti) on 2013-11-25
affects: gvfs → libsoup
Changed in libsoup:
importance: Medium → Unknown
status: Invalid → Unknown
affects: gvfs (Ubuntu) → libsoup (Ubuntu)
Changed in libsoup:
importance: Unknown → Medium
status: Unknown → Fix Released
itzeme (launchacc) wrote :

Still affecting Ubuntu 12.04.3

Will there be a backport available?

Luke Carrier (lukecarrier) wrote :

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

This problem is still present in Ubuntu 14.04.

Rolf Leggewie (r0lf) wrote :

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

Changed in libsoup (Ubuntu Quantal):
status: Triaged → Won't Fix
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.