[gentoo-amd64] Re: Too many open files in KTorrent

[Duncan]

Nicolas MASSÉ posted <200604251632.37748.nicolas27.masse@×××××××.net>,
excerpted below,  on Tue, 25 Apr 2006 16:32:31 +0200:

> I had a problem today with KTorrent, when I tried to download a torrent
> with a lots of files in it. It gave me an error : "Too many open files".
> So I ran ulimit -n 32768 and started ktorrent from the shell but I have
> now the following errors in the console :
>
> QSocketNotifier: Socket descriptor too large for select()
> QSocketNotifier: Internal error
>
> In the man page from select(2) we can read :
>
> "The default size of   FD_SETSIZE is currently 1024. In order to
> accommodate programs which might potentially use a larger number of open
> files with select, it is possible to increase this size by having the
> program define FD_SETSIZE before the inclusion of any header which
> includes  <sys/types.h>."
>
> Don't you think it's a bit strange to have a maximum number of open
> files defined at runtime (ulimit) and another limit (a C constant)
> defined at compilation ?

No.  Some reasonable default limit must be set, and 1024 is a reasonably
sane default.  An app can override that default if necessary.  For the
vast majority of applications, 1024 files should be plenty.  Set the
default higher than that and you are just begging for a buggy application
to DoS the system.  It's still possible to do it deliberately with an
override, but in that case it'd have to be a deliberate attack.  The
default guards against the unintended.

> Do you think I should report this as a bug against KTorrent ? KDE ? Qt ?
> libc ? something else ?

I'd say KTorrent, as that's what's failing to change the normally
reasonable default, for the special case that is KTorrent.  If it's simply
using a library there, as is possible, and the override needs to be in the
library, they can bug it upstream or ask you to do so.  It's possible,
however, that the 1024 default is a reasonable limit for the library as
well, and ktorrent will need to statically link its own copy, with the
necessary change incorporated.

It may instead be more reasonable to change ktorrent to be more
conservative with the resources it has, using them more wisely.  Instead
of doing them all at once, it may have to break the torrent up into 1024
file segments (actually less, given STDIN/OUT/ERR and any other
housekeeping FDs it may need), or simply handle them one by one.  Maybe it
already does and the bug is that it's using exactly 1024, having forgotten
that STD* will normally use at least three descriptors.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list