Well, not really any answers to this yet. I got two responses from
people who have experienced this same problem.
firstname.lastname@example.org (Bill Eshbach)
email@example.com (Slezak L. P. (Paul))
Their workaround is not to use the diskinfo agents to do any
monitoring. Paul Slezak said he had the same problem on SNM 2.1
monitoring a 4/670 running 4.1.3. I suspect that it uses the same
na.diskinfo agent as SNM 2.0 for monitoring SunOS 4.x systems.
What I have found is a bug in SunSolve:
Bug Id: 1110613
Release summary: 2.0
Synopsis: many na.diskinfo processes running on client machine
This bug was supposed to be fixed in the SNM patch 100770-02 (now at
revision -06). Obviously it was not completely fixed. We have a service
call in with Sun, so we'll have to wait and see what the engineers at
SunConnect have to say.
-- Glenn Satchell firstname.lastname@example.org | "This is a unix system. Uniq Professional Services Pty Ltd ACN 056 279 335 | I can do this easy." PO Box 70, Paddington, NSW 2021, (Sydney) Australia | Phone 02 360 7434 Pager 016 287 000 Fax 02 331 2572 | - Lex, Jurassic Park "Sun Accredited System Consultants" |
> > Hi folks, > > We are running SunNet Manager 2.0 on an SS2 with SunOS 4.1.3. > > I have a strange problem where client machines are hanging or crashing > due to many na.diskinfo processes running on them. In one instance > there was over 280 processes running on a SS690 that normally sits > around the 100 mark. SNM patch 100770-06 has been installed on all the > machines without making any noticeable difference. > > The problem occurs on all the machines where we run na.diskinfo. We > have set up an event to check for the disk capacity exceeding 85% and a > second event at higher priority when it exceeds 95%. The client > machines are SS2, IPX, SS10, SS690, all running 4.1.3. > > The na.diskinfo will behave normally for upto several hours or days, > then in a period as short as 5 minutes it will misbehave and there will > be 40, 50 or more copies of it running. > > There are no error messages in /var/adm/messages until the process > table fills up or we run out of swap. > > There aren't a lot of patches installed on these systems. The sun4m's > have patch 100726 installed (sorry don't know which revision but I > don't think it is a problem since the sun4c's behave the same way), SNM > patch 100770-02 was installed initially with SNM, then upgraded to the > -06 version, but otherwise they are pretty clean. > > Any ideas, suggestions, or further questions are welcome. I'll > summarise results to the list. > > regards, > -- > Glenn Satchell email@example.com | "This is a unix system. > Uniq Professional Services Pty Ltd ACN 056 279 335 | I can do this easy." > PO Box 70, Paddington, NSW 2021, (Sydney) Australia | > Phone 02 360 7434 Pager 016 287 000 Fax 02 331 2572 | - Lex, Jurassic Park >
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:57 CDT