Summary : lpd problem under SunOS 4.1.1

From: Kam Tim Chan (tim@tcs.com)
Date: Thu Apr 25 1991 - 19:03:12 CDT


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

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



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