Date: Mon, 22 Jul 2002 18:36:45 +0200 From: Stefan Schwarzer <sschwarzer@sschwarzer.net> To: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: top(1) blocks - SOLVED (and another question) Message-ID: <3D3C349D.9020502@sschwarzer.net> References: <3D3AD89E.3000104@sschwarzer.net> <20020721195730.GH40625@dan.emsphone.com> <3D3B3144.6010603@sschwarzer.net> <3D3B37EE.6010607@sschwarzer.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Dan
Stefan Schwarzer wrote:
> Ooops, I think I should be root for ktrace'ing :-)
>
> I've made kdumps as root now on my home machine and the server. I'll
> look into them and will describe my findings then.
Now follows the description and what I did to get top(1) to work. This
results in another question to which answers would be very much
appreciated. :-)
Running top as root and pressing ^T revealed that top most (at least
practically) of the time was stuck at a select call. Looking at the
trace dump showed that one NIS entry was read repeatedly. (Some
site-specific data had to be concealed here.)
46552 top CALL gettimeofday(0xbfbff334,0)
46552 top RET gettimeofday 0
46552 top CALL getpid
46552 top RET getpid 46552/0xb5d8
46552 top CALL getsockname(0x4,0xbfbfef80,0xbfbfef60)
46552 top RET getsockname 0
46552 top CALL gettimeofday(0xbfbff334,0)
46552 top RET gettimeofday 0
46552 top CALL getpid
46552 top RET getpid 46552/0xb5d8
46552 top CALL getsockname(0x4,0xbfbfef80,0xbfbfef60)
46552 top RET getsockname 0
46552 top CALL sendto(0x4,0x80d8968,0x60,0,0x80d8008,0x10)
46552 top GIO fd 4 wrote 96 bytes
"GB%¹\0\0\0\0\0\0\0\^B\0\^A\M^F\0\0\0\^B\0\0\0\^C\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\^Rrz.tu-clausthal.de\0\0\0\0\0\^Tmaster.passwd.byna\
me\0\0\0\^Duserid1"
46552 top RET sendto 96/0x60
46552 top CALL gettimeofday(0xbfbff29c,0)
46552 top RET gettimeofday 0
46552 top CALL select(0x5,0xbfbff30c,0,0,0xbfbff294)
46552 top RET select 1
46552 top CALL recvfrom(0x4,0x80d8068,0x900,0,0xbfbff2fc,0xbfbff278)
46552 top GIO fd 4 read 100 bytes
"GB%¹\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0Buserid1:
<encryped pw>:<user>:<group>::0:0:<fname> <lname>:/home/bin/userid1:\
/bin/csh\0\0"
46552 top RET recvfrom 100/0x64
This sequence was repeated over and over. In consecutive sequences
only the first characters differed. For example, in the next sequence
both of the two strings started with "HB" instead of "GB", so this
seems to be some kind of counter.
Because it looked like that there was something special with this user
(userid1), I examined /etc/passwd via vipw(8). A part of the NIS
entries was:
+userid2:::grp1:::::/srv/home/userid2:/usr/local/bin/bash
+userid3:::grp1:::::/srv/home/userid3:/usr/local/bin/bash
+userid4:::grp1:::::/srv/home/userid4:/usr/local/bin/bash
+@netgrp1:::grp1::::::/usr/local/bin/bash
+userid1:::::::::
+userid5:::::::::
After experimenting a bit it turned out that always the user
immediately after the netgrp1 netgroup entry was the one which showed
up in the repetive system calls when ktrace'ing top.
Putting the netgrp1 entry after all individual accounts solved the
problem of the stuck top.
Now my question: Can anyone explain this behaviour? I've read
passwd(5) and can see no reason why the problem with top should have
happened in the first place.
Stefan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D3C349D.9020502>