[RFC] Increase default ulimit nofile

Jon Masters jcm at redhat.com
Thu May 21 16:31:09 UTC 2009


On Thu, 2009-05-21 at 17:07 +0100, Bastien Nocera wrote:
> On Thu, 2009-05-21 at 01:49 -0400, Jon Masters wrote:
> <snip>
> > I like podcasts. A lot. I also like rhythmbox (mostly). I've been
> > wondering recently why I would occasionally not be able to download
> > podcasts in rhythmbox. It seemed to be related to when I was connected
> > to a particular VPN and so I had dismissed it as being network DNSness
> > weirdness. But then it started happening much more often. Tonight, I
> > decided it was probably more than occasional network weirdness.
> > 
> > So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo
> > packages, cscopes, hacked up source, etc. later on, I discover the
> > "problem" is in abstraction layer number 2 - totem-pl-parser. So I
> > download the source to this package also, rebuild and hack it up. I
> > eventually discovered that various GError objects were happily telling
> > me that the maximum number of open files had been exceeded, but totem
> > never exposes this to rhythmbox, and the latter just has no idea what
> > the heck is causing it to fail. Some serious fail happening there.
> 
> Can I have my bugzilla?

Filing upstream totem bug and RH BZ at the moment.

> (and some proof that totem-pl-parser is leaking descriptors...).

There's some code in there looking for a PROP_DEBUG set on the parser -
am I supposed to set that by passing some option to rhythmbox? rhymbox
-d didn't seem sufficient. Isn't there some ENV var I can set to get it
to spew out a lot more useful info?

I think all you need to do is create a long playlist of podcasts and
watch what's happening in totem-pl-parser. Aside from the possible
leaking of descriptors, if you look at around line 660, you'll see:

stream = g_file_read (file, NULL, &error);
if (stream == NULL) {

	<couple of error cases caught but not max open files>

}

The GError 'error' object knows what failed though.

Jon.





More information about the fedora-devel-list mailing list