Accepting new network connection: Invalid argument about toaststunt HOT 6 OPEN

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?

from toaststunt.

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

from toaststunt.

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.

from toaststunt.

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?

from toaststunt.

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.

from toaststunt.

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.

from toaststunt.