Thanks to Deborah Crocker and Daniel Nilsson. We had two replies (copied below), but briefly: 1) ypbind using 50% of CPU - no solution for us. Our correspondents suggest that it might be a version mismatch between client and server or running both a master and a slave on a single system. We did try to update patches on all systems, but this does not appear to help and the problem systems are pure clients, with no NIS master or slave running. 2) nscd using 50% of CPU - killed nscd, it isn't needed, patches didn't help. 3) samba won't print - went away on its own accord. 4) lpsched failing with "memory allocation error" - we will simply discard the AXIS box. The box was a disappointment anyway. Although it claims to support lpr and windows printing, it seems to use a proprietary protocol and depend on special AXIS drivers loaded on the spooling computer to work. The driver for Solaris seemed to stop working at Solaris 2.8 10/00. 5) only root can print - mode for /tmp did not allow write by all. This happened when /tmp was moved to another partition and was our fault, of course. But in our defense I could point out that /tmp is not mentioned in the FILES section of the man page for lpsched or lp. (Although many man pages omit /tmp references). I guess that it is too much to hope that a daemon that can't write to /tmp might issue an error message to the log, since as a general principle it is redundant for programs to issue error messages for user errors. >From: Daniel Nilsson <daniel@nlsn.nu> > >Is your NIS-slave/master running Solaris 7 or 8? > >We had the same problem as 1 and 2 below until we switched to a >NIS-slave with Solaris 7 (we were using SunOS 4.1.4 before... *sigh* ) > >From: Deborah Crocker <crock@bama.ua.edu> > >I just reviewed a machine that showed problem >1. In that case the user >had mistakenly told it that it would be an NIS slave when he configured >it. So, even though it was a client it was running ypserv, too. Under >/var/yp there was a domain subdirectory with some old maps in it. >We removed this and rebooted to make sure that ypserv did not restart and >all has been well since. > >Regarding >2, I had another machine that was running both DNS (slave or >secondary) and nscd. We had very poor performance in some of network >connectivity (telnet connections to the machine took many seconds). I >turned off host name caching (enable-cache hosts no) and that problem >cleared up. It really isn't needed if the machine is DNS server. Also >after reviewing the man pages for nscd and nscd.conf, I changed several >of the caching parameters. You get the current statistics from nscd by >executing "/usr/sbin/nscd -g" then you can see which caches are not sized >correctly. This was on a Solaris 2.6 machine but applies to the Solaris >8 stuff. This doesn't exactly match the situation with your non-DNS Sol >8 clients, but reviewing the caching statistics and tuning may help. > >D. Crocker > >*********************************************************************** > Dr. Deborah Crocker deborah.crocker@ua.edu > Unix System Project Leader http://bama.ua.edu/~crock > Seebeck Computer Center 205-348-3758 > University of Alabama Fax: 205-348-3993 > >On Tue, 8 May 2001, Daniel Feenberg wrote: > >> >>We are running Solaris 8 10/00 on our new SunBlade 100 as an NIS, lpd, DNS >>and Samba server at the center of a small network and experience the >>following anomalies: >> >>1) On several Solaris 8 clients ypbind will run fine for several days, and >>then start to require 50% or more of the CPU time. Once in this state it >>continues to use that much CPU until killed. While it is so busy, it still >>handles requests, although "ypwhich" reports that no server is bound. If >>we do "ypstop;ypstart" it goes back to 1% of CPU until the problem >>returns. >> >>2) Process nscd (which is part of the Solaris default install) has started >>to take 30% of CPU time on several Solaris 8 clients which never did that >>before. >> >>3) If we restart lpsched then SAMBA is unable to print until the computer >>is rebooted. All jobs through SAMBA simply disappear. Since SAMBA restarts >>for each use, this is a bit of a surprise. >> >>4) lpsched will run fine for several hours, then all print requests will >>fail with "lpsched: Memory allocation failure" in the log file. Stopping >>and starting lpsched will fix the problem until it returns. This is >>one we finally were able to fix, by removing an entry from printers.conf >>pointing to an AXIS printserver. >> >>5) Ordinary users are no longer able to print, however root can. We >>have checked as many permissions as we could think of (e.g. >>/var/spool/lp/logs, /var/spool/lp/tmp) to no avail. >> >>Help with any of these issues would be much appreciated. We will summarize >>for the list. >> >>Daniel Feenberg >>feenberg@nber.org >> >>Mohan Ramanujan >>mohan@nber.org >>Received on Thu May 10 14:06:53 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:54 EDT