Peer messages causing socket error

[zalloy]

Nicotine+ version: 1.4.3 unstable
Operating System/Distribution: Kubuntu 20.04 (Focal)

Description: After doing a few searches, I get a lot of peer messages showing up in the log window, followed by "Major Socket Error: Networking terminated! [Errno 24] Too many open files". The peer messages are a variety of types (1028, 3333, 1541, 260, 1797, 14592, 10752), and are coming from a number of different users.

Expected Behavior: I don't think I should be seeing these peer messages popping up, and shouldn't be getting the socket error.

Steps to reproduce:

1. Open Nicotine+ and connect to the network.
2. Search for a few different artists (this time, I searched for Led Zeppelin, Heart, and U2).
3. After a few minutes, you should see the messages in the log window.

Additional context:
Screenshot

[mathiascode]

Has this happened before, or approximately when did it start happening?

[hboetes]

I had this too, turned out I had to increase the number of open files allowed. This can be done with ulimit and/or whatever mechanism used in your OS.

[mathiascode]

Might have to tweak the values a bit again, it shouldn't have to be necessary to manually allow more open files.

[hboetes]

On OpenBSD it looks like this in /etc/login.conf`

        :openfiles-max=1024:\
        :openfiles-cur=512:\

So without user intervention 512 would be the limit.

[mathiascode]

What is the output of ulimit -H -a (hard limits) and ulimit -S -a (soft limits)?

[hboetes]

I take it you want the default values for mortal users. Not the output for me.

$ uname -a
OpenBSD dahud 6.7 GENERIC.MP#2 amd64
dahud$ ulimit -H -a
time(cpu-seconds)    unlimited
file(blocks)         unlimited
coredump(blocks)     unlimited
data(kbytes)         786432
stack(kbytes)        32768
lockedmem(kbytes)    4038752
memory(kbytes)       4038752
nofiles(descriptors) 1024
processes            256
$ ulimit -S -a 
time(cpu-seconds)    unlimited
file(blocks)         unlimited
coredump(blocks)     unlimited
data(kbytes)         786432
stack(kbytes)        4096
lockedmem(kbytes)    1346250
memory(kbytes)       4035896
nofiles(descriptors) 512
processes            128

[mathiascode]

Damn, that's an awfully low hard limit. Oh well, perhaps a 512 Nicotine+ limit on these kind of systems will do to prevent complaints about too many open files.

[hboetes]

Yes, typical OpenBSD stuff. Perhaps you could make nicotine+ read the limit and use what's available, with an upper limit or something like that? Post a warning to the logs when it's ridiculously low?

[zalloy]

For me, the output of ulimit -H -a is:

-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             unlimited
-c: core file size (blocks)         unlimited
-m: resident set size (kbytes)      unlimited
-u: processes                       127868
-n: file descriptors                1048576
-l: locked-in-memory size (kbytes)  65536
-v: address space (kbytes)          unlimited
-x: file locks                      unlimited
-i: pending signals                 127868
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 0
-N 15:                              unlimited

The output of ulimit -S -a is:

-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-m: resident set size (kbytes)      unlimited
-u: processes                       127868
-n: file descriptors                1024
-l: locked-in-memory size (kbytes)  65536
-v: address space (kbytes)          unlimited
-x: file locks                      unlimited
-i: pending signals                 127868
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 0
-N 15:                              unlimited

[mathiascode]

@zalloy and @hboetes Can you test if this branch works better (with the OS's default file limits)?

git clone -b openfileslimit https://github.com/mathiascode/nicotine-plus

[hboetes]

I just tried it, really quick, with a mortal account and, it works. :-)
I want to migrate my nicotine to another account anyway, so I'll be testing it a lot more.

[zalloy]

I tried it for a bit. The issue described in this bug report seems to be gone now. However, I noticed a couple of other issues:

1. The "Download folder(s)" option no longer works. You either have to use "Download folder(s) to" and specify a directory, or select the individual files and specify a directory to download them to.

2. After a bit, downloads seem to "die" or just stop working. Files show as queued, but trying to get the place in the queue for those files does nothing, and retrying also does nothing. The only way to get those downloads to retry is to restart Nicotine+.

[mathiascode]

1. Any error messages? Which folder from which user did you attempt to download?
2. Any error messages? Any examples of files that fail?

[zalloy]

@mathiascode No error messages were displayed for either of those issues. I neglected to note the user/folder where I experienced the first issue. Going to continue testing to see if I can reproduce it.