Re: top(1) blocks - SOLVED (and another question)

2002-07-22 Thread Stefan Schwarzer

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 [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message



Re: top(1) blocks - SOLVED (and another question)

2002-07-22 Thread Stefan Schwarzer

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 [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message