SUMMARY: NIS troubles at boot (rc)

From: Stephen Dowdy (
Date: Wed Feb 12 1992 - 19:31:20 CST

Sorry this took so long...

Anyway, I received several responses related to my message regarding having a loss
of services at boot time via NIS. The most promising of which seems to be
that having any blank lines in the services map will cause some services to not
be visible (apparently only) during the rc script at boot. Syptoms include
inetd indicating it can't find the 'login/tcp' service, which disables rlogin,
and lpd saying it can't find 'printer/tcp', disabling remote printing. (both of
which can be reset after boot via restart, or SIGHUP)

I found a blank line in my services file at the end, and changed my NIS makefile
code to build the services map to be:

        services.time: $(DIR)/services
                @(awk 'BEGIN { OFS="\t"; } $$1 !~ /^#/ { if (NF > 1) print $$2, $$0 }' \
                $(DIR)/services $(CHKPIPE)) | $(MAKEDBM) - \

                @touch services.time;
                @echo "updated services";

                @if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) services.byname; fi;
                @if [ ! $(NOPUSH) ]; then echo "pushed services"; fi

So that lines w/o at least 2 non-comment entries are not stored in the map.

Thanks to:

uunet!!gpr (Gary Richardson)
uunet!!gfr (Glenn Roberts)
uunet!!frankh (Frank Hoeflich)
uunet!goshawk.LANL.GOV!smc (Susan Coghlan)

Begin Included responses:
From: uunet!!gpr (Gary Richardson)

I remember seeing this problem when I worked at Sun. We discovered that
our problem was that our NIS master was running 4.1. The NIS slave that
the machine was binding to was running 4.1.1. The CLIENT was running
4.1. Thus when the client binded (bound?) to the 4.1.1 slave, we'd
see the problems you are having.

As a test, in /etc/rc.local I manually ypset the client to a 4.1 slave
and the problem didn't happen.

I don't know if they ever resolved the problem (I left before that had
occured). As far as I know it was/is a bug, although I could be wrong.

So, I'm not sure I'm being of any help to you, but maybe this could lead
you in a direction to a solution.

From: uunet!!gfr (Glenn Roberts)

you are not alone in observing this behavior. We have the exact
same problem. I had assumed that one of my sys admin staff had
messed up our rc files but now I'm convinced there's a real problem
here. We're running a mixture of 4.1 and 4.1.1 but I think I've
only seen the problem on the 4.1.1 systems.

we have not reported this to Sun yet. I suspect there's a patch.

let me know if you find an answer.


- glenn roberts, the MITRE corporation
From: uunet!!frankh (Frank Hoeflich)

        This bug has been reported several times at Sun and apparently there
is no intention of "fixing" it explicitly. You can request info from Sun
on bugs #1028855, #1049993, and #1043590 if you just want to embarrass them.
While you're at it, request patch ID 100342-01, the "NIS rebind patch" (new
version of ypbind), which fixes a slow NIS client rebinding problem. It seems
to have fixed the problem at our site (200+ machines), and we are very grateful
to our Sun PAL support engineer for intuiting that this might help the problem.
There are potential side effects to the patch (which I've never observed) so
study the README before installing. Good luck, I know this is an annoying one.

From: uunet!goshawk.LANL.GOV!smc (Susan Coghlan)

    Well I was having that problem and it turned out it was blank lines in
the /etc/services file on my yp server. Once I removed the blank lines
and did a make all the problems went away! You could also set up your
NIS Makefile to remove blank lines in the services area, it does this for
some of the other files.

Susan Coghlan
Los Alamos National Lab.
Center for Nonlinear Studies
(505) 665-1556

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:36 CDT