I am sending this summary out even though I am not sure I have fixed the
problem. It happens so intermittently that it will take a while to see if it
returns.
----------
Original message:
Hello all. We have a SS10 running 4.1.3, no patches, that is having an inetd
error very intermittently. The symptom is that when attempting to rsh a
command
on it from another host, ie, "rsh foo uptime", the user gets a timeout.
However, when a user just runs "rsh foo", the user is logged in without any
problems. Each time this has happened, the following line is in
/var/adm/messages right after bootup:
foo inetd[383]: shell/tcp: unknown service
Sending a HUP signal to the inetd process fixes the problem.
I checked Sunsolve's database, but found nothing.
----------
Thanks to:
bismark@alta.Jpl.Nasa.Gov (Bismark Espinoza)
Rasana Atreya <atreya@library.ucsf.edu>
"J.P. Racine" <admin@efni.com>
Stephen Harris <sweh@mpn.com>
"Matthew Stier" <mstier@hotmail.com>
Glenn Satchell - Uniq Professional Services <Glenn.Satchell@uniq.com.au>
"Andrew Moffat" <amof@SubaruSparcDev.subaru1.com>
davem@fdgroup.co.uk (David Mitchell)
Jochen Bern <bern@penthesilea.uni-trier.de>
Plus some me too's:
jls2013@tntech.edu
clarkson@amgen.com
I should have been more specific in my original email because the largest
number of suggestions by far was that there was a missing "shell" entry in
services and/or inetd.conf, but that was not a problem in this case. I also
noticed that this problem is the same as the one posted and summarized by
bill@solstice.digicomp.com (Bill Fenwick), and the suggestions he received
were along the same line, but his entries were ok, and his problem appeared to
not be resolved.
I did, however, receive some other suggestions. Unfortunately, I won't be able
to try some of these until the problem resurfaces. My comments are preceded
with "--" at the beginning of the line.
"J.P. Racine" <admin@efni.com>:
I have had a similar problem when I setting up a USR Xpoo rack, first do
a netstat -a and see if the service is listening or not (port 514)
-- Of course, now that I've HUP'ed inetd, it's listening just fine... :-)
"Matthew Stier" <mstier@hotmail.com>:
It sounds like your running an information services, (NIS, NIS+) and inetd is
starting before the system is able to bind to its server.
-- This could be part of the problem. I've noticed a few times where it has
taken what seems to be a long time for a host to bind to a server.
Glenn Satchell - Uniq Professional Services <Glenn.Satchell@uniq.com.au>:
How many non-comment entries are there in inetd.conf? There used to be
a problem with inetd running out of file descriptors if more than abou
50 -something services were enabled in inted.conf since by default
inetd only has 64 file descriptors assigned to it.
If this is the case the easiest fix is to edit /etc/rc (or is it
rc.local?) where inetd is called and change it to call a script:
/usr/etc/inetd.csh, the contents of which are something like:
#! /bin/csh
limit descriptors 128
exec /usr/etc/inetd $*
this increases the number of file descriptors to 128.
Also check for blank lines in your yellow pages service map and remove
any thatyou find since YP chokes on them.
-- Inetd on that machine is only running 28 serivces, so there isn't a file
descriptor problem. However, there was a blank line at the very end of the
services file on the NIS master (nowhere near the shell line, though). I've
removed it, so we'll see what happens. davem@fdgroup.co.uk (David Mitchell)
also suggested the blank line problem.
"Andrew Moffat" <amof@SubaruSparcDev.subaru1.com>:
There's no "inetd[383]: shell/tcp server looping messages" prior to this
in the messages file, is there? If so, you have a situation where lots of rsh's
are run to the machine in a short period of time. If this occurs, it can make
the inetd process think the shell service is stuck in a loop and inetd will
shut down the service. If this is the case, you can adjust the inetd
parameters, with a couple of command line flags (I don't remember them
off the top of my head - but they should be in the man page).
-- We didn't get this message, so this did not apply here.
Thanks to all,
-- ============================================================================= Sean Ward, Systems Bum +1-303-401-1530 voice Amgen Boulder +1-303-938-6244 fax 3200 Walnut St. seanw@amgen.com Boulder, CO 80301 USA ...uunet!amgen!seanw"Hopelessly lost, but making good time..." - Letterman =============================================================================
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:52 CDT