Daniel Ouellet wrote:
Alexander Hall wrote:
So, only wait.6000 in inetd.conf doesn't fix the problem if I do not
also start inetd -R 1024. Weird then based on the man page.
Weird indeed.
Anyway - why '.6000' in inetd.conf but '-R 1024'? Why not the same
number?
No logics here that I can use to justify it really. I use 6000 in
inetd.conf before, and didn't changed it as I am still looking why this
would happen. But I do not have any valid explication to give you and
your question is totally justify based on the man page. Yes it should be
the same.
Here example from the logs, when it happen all the time, but I couldn't
find why until I try for fun the inetd -R option. I used to get that
error a lots and every day and increasing the inetd.conf wait.xxx never
fixed it. But that night, I try for fun if you want as I ran out of
logical explications and my research didn't provide me anything else to
try, I did that and the results examples are below. None even sense. I
can't explain why yet anyway, just that it happen, that's all I can see
from the logs.
# zcat daemon.3.gz | grep 'Connection refused'
Dec 15 01:30:28 vtftp1 tftpd[27193]: recv: Connection refused
...
Dec 15 01:30:50 vtftp1 tftpd[5866]: recv: Connection refused
# zcat daemon.2.gz | grep 'Connection refused'
# zcat daemon.1.gz | grep 'Connection refused'
# zcat daemon.0.gz | grep 'Connection refused'
# cat daemon | grep 'Connection refused'
Oh. What you see seems to be caused by failing system calls, not any
userland inetd limit.
No idea why.
/Alexander
