> Around a month ago I posted that I had the following problem.
>
> > 1. When I "rsh -n $host ls"
> > I got " connection refused"
> > 2. If I rebooted the machine the problem seemed to go away
>
> After hours of troubleshooting and working with sun, we have come to this
> conclusion.
> The problem only happens at boot time. It is basically a NIS problem.
> What happens is inetd tries to get YP services map and fails. We see errors in
> /var/adm/messages that look like
>
> "/var/adm/messages:Dec 24 00:05:15 swigate6_sbcny inetd[168]: telnet/tcp: unknown service
> /var/adm/messages:Dec 24 00:05:15 swigate6_sbcny inetd[168]: shell/tcp: unknown service
> /var/adm/messages:Dec 24 00:05:18 swigate6_sbcny inetd[168]: time/udp: unknown service
> /var/adm/messages:Dec 24 00:05:19 swigate6_sbcny inetd[168]: echo/udp: unknown service"
>
> This is particularly apparent when we are rebooting 200 machines and the
> ypslaves are bogged down.
>
> Sun suggested solution is to bounce inetd at the end of the rc.local.
This is a well known problem, and it's actually possible to do something with
it. The problem occurs because the services.byname map is *not* a 'services by
name' map - just look at the output of ypcat. You can *not* lookup a service
by name in the services.byname map, because the key is 'port/protocol' (e.g.
25/tcp) and not service name.
The result is that the getservbyname() library routine will *sequentially
scan* half the entries in the services.byname map (on the average) for each
call. This, of course, leads to the NIS server being flooded by requests
every time you restart inetd, for instance. And you get failures like the
ones you have observed.
What you can do to cure this is to make a *new* NIS map which is keyed on
service name, *and* to rebuild the shared libc. I have included an earlier
posting I made about this particular problem.
Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no
----------------------------------------------------------------------
In-reply-to: C.R.Ritson@newcastle.ac.uk's message of 18 Jan 93 17:52:29 GMT
Newsgroups: comp.sys.sun.admin,comp.sys.hp
Subject: Re: YP services map(s)
References: <C129nH.HLs@newcastle.ac.uk>
Distribution:
C.R.Ritson@newcastle.ac.uk (C R Ritson) writes:
> WQhat I found was that our sun servers have a services.byname map
> which is keyed on the port number and protocol. They have no
> services.byport map.
>
> Can anyone enlighten me as to what services maps are supposed to
> exist. Was there once upon a time an error on Sun's part which for
> historical reasons cannot now be corrected? Are we stuck with the
> following?
>
> services.byname keyed on port number and protocol
> services.byport keyed on service name and protocol.
As far as I know there is definitely an error on Sun's part, and you should
complain *strongly* to Sun about this. It has been pointed out many times.
But you're not stuck with this. At least on your Suns you can replace the
shared library version of libc with a version which does lookup in a *real*
services.byname map. Code to do this already exists, you can pick it up with
anonymous FTP from kaa.cs.few.eur.nl, file ~/pub/getservent.tar.Z. To use it,
you will of course have to make a new NIS map which is keyed on service name
and protocol. I have included the README file from getservent.tar.Z below.
At DELAB, we run a mixed Sun/HP environment, and we cannot rebuild the shared
libraries on our HPs (wonder when HP will let us do this?). Therefore we can't
simply change the "services.byname" map to have different keys, since the code
on the HPs would be sorely confused. What I did instead was to create a new
map, called "services.byname2", which contains the *real* (keyed on name and
protocol) services map, while the original "services.byname" still exists for
compatibility with the HPs. This was an extremely simple (two line) change to
the code in getservent.c:
49,50c49,50
< #define SERVICEBYPORT "services.byport"
< #define SERVICEBYNAME "services.byname"
--- > #define SERVICEBYPORT "services.byname" > #define SERVICEBYNAME "services.byname2"On all our Suns we now use the modified libc, and it works like a charm. The reduction in network traffic to our NIS servers, for instance when restarting inetd, is dramatic.
Steinar Haug, system/networks administrator SINTEF DELAB, University of Trondheim, NORWAY Email: Steinar.Haug@delab.sintef.no, sthaug@idt.unit.no, steinar@tosca.er.sintef.no ---------------------------------------------------------------------- A replacement `getservent.c' for Sun shared standard C library.
FEATURES
o Implements *real* getservbyname() NIS maps.
o Calls to getservbyname()/getservbyport() with a wildcard protocol argument are resolved deterministically (first appropriate entry from `etc/services').
The code is based on the parsing routines from BSD sources available from several FTP sites..
INSTALLATION
Proceed to build a new libc.so as usual. Replace getservent.o from libc_pic.a with the object file generated by `cc -c -pic getservent.c'.
Replace the section in `/var/yp/Makefile' responsible for make the service NIS map with the contents of Makefile.include. Then re-make the `service' maps.
COMPATABILITY
The services.byname map will no longer be compatible with the original Sun supplied getservbyport(3) routine. getservent(3) and getservbyname(3) may still work with the library routines, albeit at a higher cost, since the new services.byname map will contain entries for all alias names also.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:53 CDT