This "who" command does not show current defunct processes.
It shows current users logged in and some debris left in /etc/utmp - usually left after killing orphan processes.
A reboot clears the list.
who -ud
Shows the list complete with PIDs. Don't kill those PIDs because the main reasons the PID would exist is
because this is a current user session or because the PID has been re-used since an "old" session died untidily
sometime in the past.
This command shows defunct processes, though they are usually harmless and disappear with time:
This issue seems to be caused by users closing Windows terminal emulation sessions without first signing off, (clicking on the X before exiting the session.)
On SCO systems, these "ghost" sessions tend to consume all the available CPU trying to re-connect.
I wrote the following script to deal with this issue, but it should be used with caution.
On SCO systems telnet sessions are named ttypnn, on HP-UX it appears they are named pts/nnn.
#!/bin/ksh
if [ $# -eq 0 ]
then
echo Usage is delete.ghosts Y or N
exit 1
fi
ps -leaf |grep ttyp >/tmp/ps.list
who >/tmp/user.list
LIST=; export LIST
separator=" "
while read a tty c
do
LIST=$LIST$separator$tty
separator=" |"
done </tmp/user.list
grep -v "?" </tmp/ps.list |grep -v root |\
grep -E -v "$LIST" >/tmp/ghost.list
while read a b user pid e f
do
if [ $1 = Y ]
then
echo for real $user $pid
echo kill -9 $pid
#kill -9 $pid
else
echo test run $user $pid
echo kill -9 $pid
fi
done </tmp/ghost.list
#
The script you post is terrifying, but I follow the basic reasoning. I would recommend that nobody runs that script on an operational system - especially one which has data.
Sorry, but it is scripts such as this which issue "kill -9" arbitarily actually cause the situation which we see with "who -d" in the original post.
If you were forced to issue a kill against orphan interractive process it should be "kill -15" or whatever "kill" signal is required by the application.
Never issue "kill -9" unless you are having trouble shutting a system down or encounter a process which is definitely stuck on impossible I/O.