Accepting new network connection: Invalid argument

[NathanTech7713]

Hello,
The title says it all pretty much.
This used to happen quite a lot and recently the issue just started popping up again.
Randomly through what is for me the night the mud will just stop accepting connections from outside (it still allows localhost, 0.0.0.0 and 127.0.0.0 to connect). When ever someone tries to connect externally it shows in the log:
Nov 9 02:04:20: *** Accepting new network connection: Invalid argument

This morning when fixing the issue I noticed 14 files in file_handles() had not been shut properly, so I went ahead and shut those, not sure if it is relevant or not.
Server version: "2.7.0_3"
$server_options.no_name_lookup = 1

Thanks in advance.

[distantorigin]

More information is required here:

• What is your listener on the default port set to bind to? Are you passing in any arguments to the binary to tweak network settings at runtime?
• What operating system are you using?
• Is this while using SSL?
• Does this occur on both IPv6 and IPv4?

[NathanTech7713]

Listener is on 7777
No TLS or SSL as far as I know. The only extra command like argument passed is -m
To make it relisten, the listen takes arguments of #0, 7777 and ["print-messages", 1]. Obviously one for ipv4 and the IPV6 address has ['print-messages' ->1, 'ipv6' -> 1]

I'm not sure if it blocks the IPV6 access as I've not actually thought to try it and not knowing what causes it to hault I'm not able to reliably reproduce.
If this helps I also have these lines in the top of the log, though I know what causes these:
Oct 31 04:39:55: *** TLS: Failed to load default certificate: error:0200100D:system library:fopen:Permission denied
Oct 31 04:39:55: *** TLS: Failed to load default private key: error:20074002:BIO routines:file_ctrl:system lib
Oct 31 04:39:55: *** TLS: Private key does not match the certificate: error:140DC002:SSL routines:use_certificate_chain_file:system lib

[NathanTech7713]

Just a follow up because I realised I did not answer all the bullet points above when seeing if there was a solution:
• What is your listener on the default port set to bind to? Are you passing in any arguments to the binary to tweak network settings at runtime? As said, port is 7777. I make no custom tweaks to the server, using the standard cmake ../ and make -j2 to compile, and at runtime doing ./moo -m mydb.db mydb.db.new 7777
• What operating system are you using? Ubuntu 16
• Is this while using SSL? No.
• Does this occur on both IPv6 and IPv4. As far as I can tell, yes. I still need to do further testing on this, as literally nobody connects on IPV6, me included! But I would assume yes.
I can confirm the file_handles theory in comment 1 is wrong, as when fixing it today their were no files open.
Thanks in advance and hope this info helps.

[NathanTech7713]

Further update as I just noticed this while updating the server to the latest commit.
When compiling with make -j2 I get:

/usr/bin/ld: warning: libssl.so.1.0.0, needed by /usr/lib/gcc/x86_64-linux-gnu/5
/../../../x86_64-linux-gnu/libcurl.so, may conflict with libssl.so.1.1
/usr/bin/ld: warning: libcrypto.so.1.0.0, needed by /usr/lib/gcc/x86_64-linux-gn
u/5/../../../x86_64-linux-gnu/libcurl.so, may conflict with libcrypto.so.1.1

Is this to be ignored or is this related?

[NathanTech7713]

Just wanted to follow up on this to find out if there'd been any progress?

The line that generates the logged error is in network.cc, and so far the only get around I've found is to unlisten, then relisten the offending object on the offending port.

How lethal would it be to put in a few lines of code here that would, upon an invalid argument fire off either an unlisten/relisten in the server itself, or just pass it off to an in moo verb to tell it to do something about it?
Currently, there's really no way of noticing from within the game that this has occurred until someone flags it up.

More info too on an interesting note is it seems to affect the sockets randomly, like there's no repeat pattern as far as I can see.

[distantorigin]

I'd suggest investigating open file descriptor limits for your flavor of Linux.

If you want to trigger an in-database event such as listening or unlistening, try handling signals in the database - see commit 8e59e0.