Well on the second thought it is
rather understandable why it always
seems to be in sleeping state, because
when it wakes from poll it immedeatly
goes to sleep in another poll call so when
something like top gets chance to run it
always sees it as sleeping. (the problem with
this stupid process is that it doesn't read from
device so it sees it readable over and over again)
Well I straced it and it seems that it performs
polling (with timeout 10msec ) on a bunch of
file descriptors which are these
lr-x------ 1 root root 64 Sep 29 15:16 106 ->
pipe:[86868]
lr-x------ 1 root root 64 Sep 29 15:16 132 ->
/proc/bus/usb/devices
lrwx------ 1 root root 64 Sep 29 15:16 140 ->
socket:[87088]
lrwx------ 1 root root 64 Sep 29 15:16 24 -> /dev/vmmon
lrwx------ 1 root root 64 Sep 29 15:16 25 -> /dev/vmmon
lr-x------ 1 root root 64 Sep 29 15:16 26 ->
pipe:[87112]
lr-x------ 1 root root 64 Sep 29 15:16 29 ->
pipe:[16717883]
lrwx------ 1 root root 64 Sep 29 15:16 31 ->
socket:[86797]
lr-x------ 1 root root 64 Sep 29 15:16 5 -> pipe:[86777]
and file descriptor that allways returns POLLIN in revents is
25 -> /dev/vmmon , go figure out what's going on :-)
By the way this process doesn't show in top -i - d 0.2 because
it always seems to have sleeping status. Isn't it weird ?
(below is the line from regular top invocation)
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
28920 boris-z 10 -10 506M 505M 496M S < 22.5 25.2 72:29 0
vmware-vmx
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
