> 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[173]: 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.
>
> Ross
> ross.stocks@nt.com
>
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.
Thanks to:
tkevens@eplrx7.es.dupont.com
tanya@ora.com
jimix@resunix.ri.sickkids.on.ca
dfalk@sqwest.bc.ca
cds@ssds.com
grobi@uni-paderborn.de
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:
--------------------
Greetings,
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.
Regards,
-+Chris
>From SunOS Patch #101618-01 Readme
Problem Description:
Bugid 1112111:
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
is 1024.
Bugid 1030599:
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'
fi
...
...
---------------------
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