lpd problem under SunOS 4.1.1

Hi everyone,

        I am sorry to not summarize earilier, partly because of too busy,

and partly because I want to wait and make sure that my solution works.

I have received quite a number of replies from sun-managers, thanks

to all who had replied, I hope you don't mind I don't post your names.

        Some suggested that they put a "sleep 5" just before starting

lpd in /etc/rc, some suggested that I might have different slave NIS

servers that are not in sync, some suggested I may have a corrupted NIS

services map, and some asked if I have 4.1.1 running on the NIS master

since my clients are running 4.1.1, and some have mentioned that I

should check the /etc/services on the NIS master to see if I have any

blank lines or tab in that file, which turned out to be my problem.

        I checked my /etc/services in my NIS master machine, and found

that I have a blank line at the end of the file, ie an extra carriage

return. As soon as I removed it, all my client machines seems to be

able to start /usr/lib/lpd and /etc/inetd without no problem. I have

waited for a few days and reboot most of the machines to make sure that's

my problem, and it seems that this simple solution had solved my problem.

The strangest thing is that, if I didn't correct the /etc/services, I

can't start /usr/lib/lpd even I put "ypcat services | grep printer" just

in front of the /usr/lib/lpd and it showed the correct line:

printer 515/tcp spooler # line printer spooler

I really don't know why it can find the correct printer service line with

ypmatch just before it start /usr/lib/lpd, but still complains about

the services is unknown. Then again, as soon as I removed the blank

line, my problem had seemed to be gone, and all machines was able to

start lpd correctly. If you have similar problem, do check your

/etc/services to remove all blank lines ... etc.

Thanks again for all those who replied.

                                                Tim Chan

================================ Address ===============================

Tim Chan, System Engineer, Teknekron Communications Systems

        (415)-649-3645 2121, Allston Way, Berkeley, CA94704

Internet :tim@tcs.com uucp : uunet!tcs!tim

============================================================================

Here is the summary of the replies :

============================================================================

From: David Maynard <dpm@ARCHONS22.ARCHONS.CS.CMU.EDU>

This is a 2nd attempt at sending this message. I noticed that the one I sent

directly to tcs.com yesterday was still sitting in my mail queue.

I ran into this same problem. I would also occasionally get a similar message

from another daemon (I think it was sendmail or syslog).

>From the error message, I guessed that NIS wasn't coming on-line fast enough

to satisfy some of the other daemons trying to start up. When they do a

getservbyname() call it returns a failure because the services map isn't in

place yet. (That was my guess anyway.) I've managed to bypass the problems by

placing a "sleep 5" command after starting NIS. This delays the rest of

the rc.local processing long enough for NIS to come up. It certainly isn't a

great "fix," but it is better than having to check each machine after a reboot

to see which daemons have to be manually restarted.

-David


--
David P. Maynard (dpm@cs.cmu.edu)
Dependable Solutions & CMU ECE
Pittsburgh, PA 15213
--

============================================================================
From:cdr@acc.stolaf.edu

>> printer/tcp : unknown services .....

Tim - we have experienced the same problem. Sun is "working" on a fix --
our contact person is "Margret Kapica" @ 415-336-1455. The service number
is 646-867. I haven't heard from her in quite a while, but I think the
more people that call to report this problem, the higher a priority it
will get for being fixed. It really is a pain!

Craig
--
Craig D. Rice UNIX Systems Specialist/Network Analyst
cdr@acc.stolaf.edu Academic Computing Center, St. Olaf College
+1 507 663-3631 1520 St. Olaf Avenue
+1 507 663-3549 FAX Northfield, MN 55057-1098 USA

From:mark@gest20.SINet.SLB.COM
Tim,
hello yes I have the same problem and so far have only found one way to solve
it. I put
sleep 5 before /usr/lib/lpd in /etc/rc. It seems like inetd might not
be completely finished initializing itself, but I am not sure.

Please copy me any other replies.

Mark Read Sunsystem manager Geco-Prakla Stavanger Norway

============================================================================
From: David Maynard <dpm@ARCHONS22.ARCHONS.CS.CMU.EDU>
Status: R

I ran into this same problem. I would also occasionally get a similar message
from another daemon (I think it was sendmail or syslog).

>From the error message, I guessed that NIS wasn't coming on-line fast enough
to satisfy some of the other daemons trying to start up. When they do a
getservbyname() call it returns a failure because the services map isn't in
place yet. (That was my guess anyway.) I've managed to bypass the problems by
placing a "sleep 5" command after starting NIS. This delays the rest of
the rc.local processing long enough for NIS to come up. It certainly isn't a
great "fix," but it is better than having to check each machine after a reboot
to see which daemons have to be manually restarted.

-David
--
David P. Maynard (dpm@cs.cmu.edu)
Dependable Solutions & CMU ECE
Pittsburgh, PA 15213
--

============================================================================
From:starner@ISF.Unisys.COM (Mark Starner)
make sure you have no blank lines in your /etc/services file on your
NIS master... blank lines cause it to do what you mentioned....

take out or turn into comments any blank lines, and remake yp map -- the
problem will go away if this is your problem

Mark

============================================================================
From:Lovstrand@europarc.xerox.com
Status: R

> I kept getting the following problem and couldn't find out what> causes it. When any of our SS1+, IPC, SS2 running SunOS 4.1.1 got rebooted,> at the end of the reboot sequence it'll try starting the lpd printer > services, but then complains about :> > printer/tcp : unknown services .....

Yup, that's right. The problem is that YP (sorry, NIS) lookups have a
tendency of failing when under attack from more than one client. In this
case lpd is fired up just after inetd starts hammering on the services map,
which tickles the bug.

We just delay lpd for a couple of seconds and haven't had any further
problems since that change:

[/etc/rc]> if [ -f /usr/lib/lpd ]; then> rm -f /dev/printer /var/spool/lpd.lock> (sleep 10; /usr/lib/lpd) & echo -n ' printer (delayed)'> fi

Good luck,
--Lennart <Lovstrand@EuroPARC.Xerox.COM>
Rank Xerox EuroPARC, 61 Regent St, Cambridge, CB2 1AB, England

============================================================================
From:ldk@udev.cdc.com (ld kelley x-6857)

Tim,

I see the same problem here and have traced it down to having yp
slave servers that are not sun's. We have a sun yp master, 3 sun slave
servers and a number of MIPS slave servers. If during the bind process,
a booting sun binds to one of the MIPS servers, lpd does not work. I
have fixed this problem here be adding a ypset sun-server after the
ypbind in rc.local. This also means that you must start ypbind with
the -ypsetme option. This fixed the problem here.

larry

ldk@udev.cdc.com

From: Carol Wood <cwood@flory.uchicago.edu>

Tim - I am experiencing this same problem. If you get an answer, would you
forward a copy to me. Thanks.

-Carol Wood
System Manager James Franck Institute
cwwod@control.uchicago.edu

============================================================================
From:rackow@antares.mcs.anl.gov
Status: R

Take a look at the /etc/services file on the server. You can't have any
blank lines in it. If there is a blank line things break. This is actually
true of any of the NIS (yp) maps. If there is a blank line, take it out and
remakethe maps.You could have some bigger problems and have to kill all
the yp stuff on the machines and remake from scratch if things don't go
smooth. The "service" for yp may not be usable in the maps. Contact me
if you run into problems or this message doesn't point you in the right
direction.

--gene

============================================================================
From: "Manavendra K. Thakur" <thakur@zerkalo.harvard.edu>
Status: R

>>>>> On Tue, 16 Apr 91 15:27:43 PDT, Kam Tim Chan <tim@tcs.com> said:

> I kept getting the following problem and couldn't find out> what causes it. When any of our SS1+, IPC, SS2 running SunOS 4.1.1> got rebooted, at the end of the reboot sequence it'll try starting> the lpd printer services, but then complains about :

> printer/tcp : unknown services .....

> and the /usr/lib/lpd never got started. Therefore, when someone try> to print, it'll complain :

> lpr: connect: Connection refused jobs queued, but cannot start> daemon.

This happened to us too. Check the /etc/services file (or whichever
file is the master NIS services file) on the NIS master machine. If
there are any blank or corrupted lines in that (plain-text) file, the
NIS services map will be corrupted.

When we fixed our services file, the problem went way. Note that the
problem only seemed to start up when we upgraded to SunOS 4.1.1 (we
bypassed 4.1, so I don't know whether blank lines were permissable in
that release).

Good luck!

Manavendra

============================================================================
From:cwilson@adl.austek.oz.au (Chris Wilson)

One possible reason for the problem is that the NIS (yellow pages)
server is too slow and is not responding quickly enough when lpd
attempts to retrieve the entry for printer. I get the same problem
with random services sometimes (like when a lot of machines decide
they want an old microvax II to be their YP services).

Perhaps the server needs a reboot, or its maps remade. Or possibly you
could reorganise the services file on the server so that it finds
printer more quickly, leaving the unused entries lower down the file.

Do you have services files on all of your Yp clients. I keep them
their anyway even though they are not supposed to be needed if you use
YP.

Regards,
Chris Wilson
Austek Microsystems Pty. Ltd., Technology Park, Adelaide, SA 5095 Australia
Phone: +61-8-260-0155 Fax: +6-18-260-8261
ACSnet: cwilson@austek.oz Internet: cwilson@austek.oz.au
UUCP: uunet.uu.net!munnari!austek.oz.au!cwilson

============================================================================
From: "John R. Kilheffer" <amp19263%garfield.amp.com@RELAY.CS.NET>

Check your "services" file. Make sure that each of columns are seperated by a
"tab" character and that there are NO spaces between the columns. For some
reason, a single misplaced space can completely mess up the services stuff.

We had the same problem here and I finally stumbled on it. Give it a whirl
and see if this fixes you up.

John Kilheffer
Supervisor, EMCS Operations/Workstation Group
amp19263@garfield.amp.com

============================================================================
From:holle@ASC.SLB.COM

Are you sure you have this in your /etc/rc:

if [ -f /usr/lib/lpd ]; then
rm -f /dev/printer /var/spool/lpd.lock
/usr/lib/lpd; echo -n ' printer'
fi

And are you sure you have /dev/printer, etc.?
Are you sure the workstation can see the yp maps?
Once the machine is up (and lpd has failed), do a
"ypwhich" to see what machine it's bound to. Then,
go to that machine and do a "ypcat services|grep printer"
to make sure that it can see the printer. It's got to
be something simple.

-Kathy Holle Schlumberger
UNIX Systems Manager Austin Systems Center
ARPANET:holle@asc.slb.com 8311 North FM 620 Road
UUCP: uunet.uu.net!asc.slb.com!holle P. O. Box 200015
Austin, Texas 78720-0015
512-331-3000 (operator)
512-331-3646 (direct line)

============================================================================
From: Tad Guy <tadguy@abcfd01.larc.nasa.gov>
To: Kam Tim Chan <tim@tcs.com>
In-Reply-To: Kam Tim Chan's message of Tue, 16 Apr 91 15:27:43 PDT
Subject: lpd problem under SunOS 4.1.1
Status: R

> I kept getting the following problem and couldn't find out what> causes it. When any of our SS1+, IPC, SS2 running SunOS 4.1.1 got rebooted,> at the end of the reboot sequence it'll try starting the lpd printer > services, but then complains about :> > printer/tcp : unknown services .....> > and the /usr/lib/lpd never got started. Therefore, when someone try to> print, it'll complain :> > lpr: connect: Connection refused> jobs queued, but cannot start daemon.> > and then lpq will say "no daemon present", etc. Occasionally the same > w/s will be fine, but I would say 8 out of 10 reboot will have this lpd> problem. However, one can login and start the lpd daemon manually without> any problem, even just after it gives the login prompt. It is very > disturbing as starting lpd manually on all these machines everytime it> reboots is no fun. I've called Sun, but doesn't seem to know. I've> made sure that :> > printer 515/tcp spooler # line printer spooler> > was in the NIS services map.

Do you have more than one ypserver? Make sure the services maps are
up to date on *all* the ypservers for your domain. When it fails, try
running `ypwhich' to see who has the bad maps...
...tad

============================================================================
From:edm@MDI.COM (Ed Morin)
Message-Id: <9104171614.AA01272@fh20c.MDI.COM>
To:tim@tcs.com
Subject: Re: lpd problem under SunOS 4.1.1
Status: R

It's probably because your NIS server isn't running 4.1.1

============================================================================
From:dal@gcm.com (Dan Lorenzini)

Your message dated: Tue, 16 Apr 91 15:27:43 PDT
--------> > Hi,> I sort of remember that this might have asked before, but no sure, > if so, please excuse me.> > I kept getting the following problem and couldn't find out what> causes it. When any of our SS1+, IPC, SS2 running SunOS 4.1.1 got rebooted,> at the end of the reboot sequence it'll try starting the lpd printer > services, but then complains about :

> printer/tcp : unknown services .....

> and the /usr/lib/lpd never got started. Therefore, when someone try to> print, it'll complain :

> lpr: connect: Connection refused> jobs queued, but cannot start daemon.

> and then lpq will say "no daemon present", etc. Occasionally the same > w/s will be fine, but I would say 8 out of 10 reboot will have this lpd> problem. However, one can login and start the lpd daemon manually without> any problem, even just after it gives the login prompt. It is very > disturbing as starting lpd manually on all these machines everytime it> reboots is no fun. I've called Sun, but doesn't seem to know. I've> made sure that :

> printer 515/tcp spooler > # line printer spooler

> was in the NIS services map.

Tim,

This sounds like a YP problem. Perhaps you have more than one yp
server on your network and one of them has bogus information? Or
perhaps your yp server is not responding fast enough?

Dan Lorenzini
Greenwich Capital Markets
600 Steamboat Road
Greenwich, CT 06830
dal@gcm.com

============================================================================
From:htg@bassale.cray.com (Harold Longley)

> I kept getting the following problem and couldn't find out what> causes it. When any of our SS1+, IPC, SS2 running SunOS 4.1.1 got rebooted,> at the end of the reboot sequence it'll try starting the lpd printer > services, but then complains about :> > printer/tcp : unknown services .....

If you get any answers, please forward the information to me (htg@cray.com).
I`m been stumped by this problem.

--

Harold Longley Cray Research, Inc.
htg@cray.com or uunet!cray!htg 655E Lone Oak Drive
612/683-3031 Eagan, MN 55121 USA

============================================================================

[23749 byte] By [CodeProf.com] at [2007-12-25 7:22:00]