Daniel Ouellet wrote:
Alexander Hall wrote:
Hmmm... Are you just not looking at it totally backwards, maybe? Maybe
Sometime I sure can be backwards. (;>
:)
inetd (with the .6000 suffix) just tries to eat more
connections/sockets/handles/whatever than the system (or the user tftp
is being run as) is allowed to?
But here having .6000 suffix, doesn't imply it actually use 6000, but
that the limits would be 6000. Just for fun, I will put 1024 there and see.
Ok, I'll rephrase into "...just allows for eating more...". I meant that
something else in the system may not allow, or cope with, the number of
connections that inetd tries to serve, so that you're in fact better off
with a lower value.
However, If you _always_ had the .6000 suffix in inetd.conf, I should
be wrong.
Yes, I had the .6000 there before adding the -R 1024 manually and
restarting inetd.
# ls -al /etc/inetd.conf
-rw-r--r-- 1 root wheel 2403 Aug 25 04:18 /etc/inetd.conf
Still haven't changed it yet. As I said, I started inetd manually for
testing with -R. (;> Been there for what, 4 months now.
# cat /etc/inetd.conf | grep tftpd
tftp dgram udp wait.6000 root
/usr/libexec/tftpd tftpd -ls /distribution/phones/cisco
#tftp dgram udp6 wait root /usr/libexec/tftpd tftpd
-s /tftpboot
# ps -auxw | grep inetd
root 15222 0.0 0.1 600 1136 ?? Is Sat09PM 0:01.79 inetd
-R 1024
If you cannot come up with something else, I'd recommend sending a new
post to misc@ describing the actual issue you're having (i.e. tftp
through inetd causes 'recv: Connection refused'). I bet there are many
people here that can push you in the right direction from there. :)
May be, but I don't like starting new treads on the same subject. Might
be worth it however.
...which is a good thing, but I do not think it is quite the same
subject anymore. Well, you decide. :)
Thanks for all your suggestions never the less. Don't explain anything,
but was good to get someone else point of view in case I was totally
nuts! (;>
Just need to find out why next then.
Best,
Daniel
Cheers,
Alexander
