View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004267||unreal||ircd||public||2014-03-14 01:14||2014-03-14 01:14|
|Platform||Linux||OS||Debian Wheezy||OS Version||3.10.1 x86_64|
|Target Version||Fixed in Version||184.108.40.206|
|Summary||0004267: Listen block: Cannot accept connections: Invalid argument|
|Description||Fresh system with Debian Wheezy. Ipv6 Configuration successfully. Ports and IP´s are free and unbound. After install of unrealircd it produces an error with the listen blocks. I´ve noticed thats alway the second listen block from the bottom and I changed the sequenze of the listen blocks and/or the ports to reproduce the error. More than once re-install unreal with the same error. Compiling finished successfully. |
Error looks like:
Cannot accept connections my.domain.de[20:30:40:50:60:70:80:1.6697]:Invalid argument
Cannot accept connections my.domain[220.127.116.11.6697]:Invalid argument
All Ip´s except the second from the bottom in the listen block will be bound by the ircd.
gcc version 4.7.2 (Debian 4.7.2-5)
GNU Make 3.81
|Steps To Reproduce||New install of unrealircd with or without ipv6, copy a valid config with more than 5 listen blocks. Start unreal and connect to it, generates the given error on Debian Wheezy. Also tried with unreal 3.2.9 and 3.2.10. Also install without 3rd party modules, but it makes no sense.|
|Tags||No tags attached.|
|3rd party modules||hideserver, netadmins|
The second error is also a fully domain:
Cannot accept connections my.domain.de[18.104.22.168.6697]:Invalid argument
Also tried with larger file descriptors than 1024. Still the same problem.
There are 2 ways to get a possible solution:
I´ve insert a *Dummy Listen Block* for the second listen block from the bottom. All needed listen blocks will created, but it generates every x-minutes an error like above with the invalid argument and the *Dummy Listen Block*.
Compiled with gcc version 4.4.5 on Debian 4.4.5-8 and copy the complete unreal-dir to the new directory. This way generates no errors with the same listen blocks. All listen blocks work perfect and are available with the specified ipv4- and ipv6-addresses.
I´ve also read something about a build bug with the gcc version 4.7.2 and the shared libraries. Maybe this can be the problem. Maybe it can be something else. I can´t locate this problem exactly. Reinstall and rebuild of the dependent packages makes no sense.
Think if I´m the only one with this strange problem, this bug report can be closed.
But thanks for your advice and help on #unreal-support.
||I'm also a Debian user, I'll upgrade to latest (am still on 7.1 now) and see if I can reproduce it when I have like 10 listen blocks.|
After x-reinstalls it won´t work. My system:
Debian Version 7.2
Linux 3.10.1 x86_64
OpenSSL 1.0.1e 11 Feb 2013
Install unrealircd22.214.171.124 with ssl and ipv6. Setup 7 Listen blocks:
IPv4: 2 ports without ssl and one port with ssl
IPv6: 2 ports without ssl and one port with ssl
The 7th and last listen block is only for server with ipv4 and ssl.
All listen blocks uses an existing ipv4/ipv6 address.
unrealircd started successfully. Seems to be no errors. If I connect to it, it generates a large log file (only for the errors) with the error "Cannot accept connections my.domain.de[20:30:40:50:60:70:80:1.6697]:Invalid argument"
Now the same steps, but install on another server:
Debian Version 6.0.7
Linux 3.6.7 x86_64
OpenSSL 0.9.8o 01 Jun 2010
Same listen blocks like above. Same config files and 3rd party modules. Runs on the other machine with all listen blocks. There´s no error.
Now I´ve copied the whole new installed unrealircd.126.96.36.199 from the other machine to this machine with the given error from above. Only had to install the other openssl 0.9.8 via dpkg.
Start the *copied* unreal188.8.131.52 with the same config files generates no error and all seven listen blocks will be created. No error.log created and everything is fine.
Maybe this can be helpful.
Also tried to reinstall OpenSSL 1.0.1e 11 Feb 2013 with no results. The same errors with the invalid arguments.
I've tried to reproduce this on Unreal 184.108.40.206 on Debian 7.2 / 3.2.0-4-amd64 with gcc 4.7.2-5. I added 10 listener blocks and connected and disconnected a series of 500 drones on several ports. I did not experience any errors.
I even turned off DEBUGMODE and remove all extra custom gcc flags I normally use, so to get a standard build (with default -O2 etc...), just to be sure since you mention gcc bugs.
When do you get the error, though? Is it near the 1000+ limit? Were you able to spot any pattern in time or what happens around it?
It's also interesting that you have this on both 3.2.9 and 3.2.10(.x) since .9 uses select() and .10(.x) uses poll().
Technically: the error you receive is 'Invalid argument' which happens upon a call to accept(). According to the Linux/glibc documentation, this can only happen when 1) addr/addrlen are wrong (but they are NULL / unused / which is fine.. so this can't be it), or 2) when the socket is not in listen mode. I suppose *2 may happen if some other code closes that file descriptor.
You were saying you can reproduce this on an UnrealIRCd without IPv6 and without 3rd party modules? How about - in addition to that - also without SSL / zip links / remote includes?
Some tests later:
I can reproduce this with the following config for UnrealIRCD:
1. SSL: N ; IPv6: N ; ZIP: N ; Remote: N
2. SSL: Y ; IPv6: N ; ZIP: N ; Remote: N
3. SSL: N ; IPv6: Y ; ZIP: N ; Remote: N
4. SSL: N ; IPv6: N ; ZIP: Y ; Remote: N
4. SSL: Y ; IPv6: N ; ZIP: N ; Remote: N
5. SSL: Y ; IPv6: Y ; ZIP: N ; Remote: N
6. SSL: Y ; IPv6: Y ; ZIP: Y ; Remote: N
All attempts without 3rd-party and remote.
I´ve checked my config again and found no errors for this strange problem.
Whole System reinstall makes no sense, the problem exists furthermore.
To answer your question:
It´s not neccessary that a lot of users / drones connects, the error occurs if I´m connect. Get also two notices (both the same: cannot accepts connections) per minute and write this error to the unrealircd-error.log. But I can wait to connect to it, the errors will be write without connect too. A 'netstat -atnp | grep irc' show the listen IP´s and ports, except 1 ip which generates the error.
But the other main question is, why does the copy of the new compiled unrealircd220.127.116.11 from the other machine runs on this machine perfectly without any error and the same config? All listen blocks were created, 'netstat -atnp | grep irc' returns the right listen ports on all configured ip´s and with 3rd-party modules and no other change (only use the old openssl version). According to that, the copy is running without any error, I don´t think it can be the file descriptor you describe above.
Compiled on the other machine:
Debian Version 6.0.7
Linux 3.6.7 x86_64
OpenSSL 0.9.8o 01 Jun 2010
Thats very strange...
Could you attach (or send me privately at email@example.com) your config.settings file (assuming you use ./Config and not ./configure directly), and also unrealircd.conf plus any files you include from there.
I suggest you xxxx out any IP's, passwords and cloak keys. But other than xxx'ing out leave it untouched.
Then I'll try to reproduce it here.
||You´ve got mail ;)|
||Thanks, got it. I'll check it out tomorrow.|
||Thanks, I can reproduce it with your configuration on my local system. I'll look into it.|
Ok, when I comment out your set::timesynch::server line (where you set your own NTP servers) then the error is gone :)
So there's a bug in that code (in the ircd).
Ok, it's a silly bug: you have 5 servers specified in set::timesynch::servers but UnrealIRCd can handle a maximum of 4 (MAXTIMESERVERS in src/timesynch.c). The silly part is that it doesn't actually check if more than 4 are specified, so that screws things up.
If you remove one IP, then it will boot fine.
I'll add a configuration check in next release :)
||Thank you syzop for spending your time to solve this problem. It works perfect and the ircd bind all listen blocks successfully. Now I´m use the newest release! Thanks ;)|
Fixed, will be in next release.
When you specified more than 4 servers in set::timesynch::server you could
experience weird issues such as a flood of 'Cannot accept connections:
invalid argument' messages. Reported by hyper_threader (0004242).