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. Jon. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
