> Fellow managers:
> Once again I get to draw upon your wealth of knowledge.
> I am starting to see a significant increase in the frequency of the
> following system message:
> inetd: ftp/tcp server failing (looping), service terminated
> For many months I never saw it. Then several months ago I began to see
> one every one or two weeks. Now it's getting to the point of several a
> day. No user or application has complained of any problems with ftp or
> telnet (or anything else for that matter - maybe I should just keep
> quiet). :-)
> I checked FAQ, SunSolve, and AnswerBook with no success.
> What does the message mean?
> TIA and, as usual, I will summarize if there is interest.
How is this list like a microwave oven? I can't understand how I survived
for so long without it!
I got six responses. Two hit the nail on the head I think, three provided
some good ideas to look for, and the other related their own experiences with
the same problem, a quick fix, and a me too.
I followed up on all the hints without finding a problem. I decided that
Chris Swanson and Juergen Peus probably had the explanation and I decided to
wait until some one complained. Someone finally did complain. They were
attempting to ftp large numbers of very small files to my system by means of
a REXX exec on a mainframe somewhere. Their exec would inexplicably hang and
not recover. If detected immediately, attempts to re-ftp would result in
messages along the lines of connection failed or refused or something like
that. I had them try putting some delay in their exec and in 30 minutes they
had successfully ftp'd ten times what they had ftp'd all morning.
Chris's followed by Juergen's explanations:
We see this alot on firewall configurations. The problem is
actually a safety feature of inetd. Inetd monitors the number of
connections a second for a particular daemon, and if it exceeds 40 (lots
of small, fast requests), then it figures that something is looping and
stops the service for a few minutes (I think 10 minutes). This was an
assumption made back in the SparcStation 1 days (when an SS1 could not
respond to that many queries). Sun has a patch out that lets you tailor
some of those variables. I have included the README from that patch -
hope it helps.
>From SunOS Patch #101618-01 Readme
The file descriptor limit on inetd is too low. This patch of inetd
make use of the hardlimit for the number of file descriptor which
inetd refuses to accept more than 40 connects per minute on a
particular socket (loop detection)
The SS1 is fast enough, that you can end up legitimately calling
rsh more than 40 times per minute.
This patch adds a new argument, "-r", to inetd that allows you to
specify number of connections allowed in the given time in seconds.
The default is to allow 40 connections in a 60 second period, E.G:
/usr/etc/inetd -r 40 60
Typically for a faster machine you might up this to 60 connections
per minute, E.G:
/usr/etc/inetd -r 60 60
You will need to edit /etc/rc to make the change permanent each
time the machine is rebooted, E.G:
if [ -f /usr/etc/inetd ]; then
inetd -r 60 60; echo -n ' inetd'
The inetd is only capable of answering a special number of queries (i think
~60 per minute). If the number of requests (per minute) is bigger than this
numer, you will get that error message.
To get inetd to work normal again, "kill -HUP <PID if inetd>" should help ;-)
Hmmm...i think there's a patch for SunOS4.1.x (i'm not sure) but i haven't
seen one for solaris :-(
Other hints and pointers:
Check for blank line(s) in /etc/inetd.conf.
Kill and restart inetd.
Check ftp/tcp entry in /etc/inetd.conf and /etc/services, check sum on ftpd,
run ftpd without inetd and ftp to it and see what happens.
Check permissions on /etc/services.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:25 CDT