I found this problem this morning, when I booted my Linux-box: the network was slow to start up, so rinetd has been started before the IP-address has been assigned to eth0.
This problem lead to another: in rinetd.c, the number of succesfull bind(2) opeartions was less than 'seTotal', so the select(2) in function selectPass was listening on non-opened handles; in my case it was handle=0 meaning standard input (which was directed to /dev/null). I ended up with 11272330 messages in my /var/log/rinetd.log saying 'accept-failed on IP=0.0.0.0 port=0'.
I think it is easy to solve with the attached patch; I successfully tested it with manually disabling networking (ifconfig eth0 down).
Commit message:
If one or more server couldn't be opened, reduce 'seTotal' to the
actual value of the opened servers. It prevents using elements
of 'seFds' that haven't been initialized with an actual handle.
Another solution would be initializing 'seFds' with invalid handles (-1).
boutell
commented
4 years ago
Hi,
I found this problem this morning, when I booted my Linux-box: the network was slow to start up, so rinetd has been started before the IP-address has been assigned to eth0.
This problem lead to another: in rinetd.c, the number of succesfull
bind(2)opeartions was less than 'seTotal', so theselect(2)in function selectPass was listening on non-opened handles; in my case it was handle=0 meaning standard input (which was directed to /dev/null). I ended up with 11272330 messages in my /var/log/rinetd.log saying 'accept-failed on IP=0.0.0.0 port=0'.I think it is easy to solve with the attached patch; I successfully tested it with manually disabling networking (
ifconfig eth0 down).Commit message:
If one or more server couldn't be opened, reduce 'seTotal' to the actual value of the opened servers. It prevents using elements of 'seFds' that haven't been initialized with an actual handle.
Another solution would be initializing 'seFds' with invalid handles (-1).