Thanks to Tim Lindgren for forwarding me the SunSolve technote that
addresses this problem, and to Ken, for pointing out some possible causes.
Gerald Gallagher
Systems Analyst
Reed Technology & Information Services
gerald.gallagher@reedtech.com <mailto:gerald.gallagher@reedtech.com>
----- Response -----
From: Timothy Lindgren
Sent: Tuesday, January 18, 2000 7:51 PM
To: Gallagher, Gerald (RTIS)
Subject: Re: shell/tcp server failing (looping)
Gerald,
I'm told this is a valid parameter for Linux, and not Solaris or SunOS. The
number after nowait.xxx is the number of connections inetd will allow at any
given time.
But there is good news... I hope it helps,
Tim
SunSolve technote 3039...
What would cause the following failure of inetd?
Mar 8 10:07:55 marge inetd[120]: shell/tcp server
failing (looping), service terminated
Mar 8 10:10:19 marge inetd[347]: shell/tcp server
failing (looping), service terminated
Problem Solution
Literally, this means that the <service> in question (shell/tcp in this
example) is getting more than 40 requests in a 60 second period, resulting
in requests for that <service> being denied.
Often, this may be the result of some underlying problem. You might have
some program trying to access the <service> that is in an infinite loop. You
should examine your programs, and make sure that this is not the case,
before you take any other steps.
This can also be the result of faster machines making legitimate requests
for the service at a rapid rate. In this case, you must reconfigure your
inetd to accept requests more rapidly. This can be done by killing and
restarting inetd with the -r option. To allow your inetd to accept 80
connections every 60 seconds, you would type the following on SunOS:
# inetd -r 80 60
And the following on Solaris:
# inetd -s -r 80 60
These modifications should also be made to /etc/rc (SunOS) or
/etc/rc2.d/S72inetsvc (Solaris) to make the changes permanent.
Note: The -r functionality is not available by default on SunOS, or on
Solaris earlier than 5.4. For those older operating systems you must install
the inetd patch: 100178 (4.1.1, 4.1.2 and 4.1.3), 101618 (4.1.3_U1), 102416
(4.1.4) or 101786 (5.3), to use the -r flag.
----- Response -----
From:
Sent: Thursday, January 20, 2000 8:54 AM
To: gerald.gallagher@reedtech.com
Subject: RE: shell/tcp server failing (looping)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Firstly you did not cause this problem by running ftp, whoever is
suggesting this does not have a clue what they are talking about.
Secondly this error means that inetd has received more than 40
connections in a second for the shell service and has therefore
assumed that there is a problem with the service and is shutting it
down. Now something must have changed to cause this. The likely
candidates are the following:-
you are using tcpd, has the /etc/hosts.allow or /etc/hosts.deny files
been edited recently, if so by whom and are the changes valid, you can
check this by doing:-
# tcpdchk -v
then you can check the particular host that is trying to connect by
doing:-
# tcpdmatch shell@remotemachinename
if all of this looks ok then check what commands the remote machine is
trying to run maybe they are not working, if it runs in a loop and now
that the commands are breaking it may run the loop way to quick and
this is hosing inetd.
If this is not clear then please mail me.
Regards,
Ken.
-----Original Message-----
We are getting the following message, caused by a process on
another SPARC trying to do some remote shell commands:
inetd[432]: shell/tcp server failing (looping), service
terminated
My search of the net discovered a work-around (not yet
tried) - edit the /etc/inetd.conf as follows:
shell stream tcp nowait.120 root /usr/sbin/tcpd
in.rshd
In the above example, another suggestion was to use a value
of "nowait.1000". No suggestions came from Sun or Solaris-specific
newsgroups, and the Sun man pages mentioned nothing about adding a numeric
value to the wait-status field.
Can anyone confirm that this is a valid work-around on
SunOS? Any other suggestions?
Everything was working fine for years. It has been suggested
that I caused this problem when I ran ftp to put a small text file on
another SPARC. (Apparently ftp was never used on this system before.) We
are running SunOS 4.1.4. Thanks.
Gerald Gallagher
Systems Analyst
Reed Technology & Information Services
gerald.gallagher@reedtech.com
<mailto:gerald.gallagher@reedtech.com>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:02 CDT