On May 21, 2009, at 12:49 AM, Jon Masters wrote:
Folks,
While digging through a fault in GNOME and Rhythmbox this evening, I
happened upon this nugget. By default, we're still living in 1970:
[jcm@tonnant ~]$ ulimit -n
1024
Now. This might be great for a honking great shared UNIX server from
the
days of yore, but it's not remotely appropriate for a modern desktop.
Especially not one layered with so many per-user daemons and layers of
abstraction as we have on modern Linux systems.
I suggest /etc/security/limits.conf be modified to include something
like the following, along with advice for sysadmins:
* - nofile 8192
Discuss.
--- background to discovering this problem ---
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.
Isn't that like putting a bigger gas tank on your Hummer? Did you file
a bz on the file descriptor leak in totem-pl-parser?
joe
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
