> GUEST wrote:
> Dave Hodgins' recent mention of htop prompted me to install it,
> and results have been surprising. As root, ps -eF yields (a few
> moments ago) 146 processes, but htop says there are 194.
>
> Command ps -eF shows one entry for console-kit-daemon.
> [root@jb jim]# ps -eF |grep console
> root 4003 1 0 25189 3328 0 Mar28 ? 00:00:00
> /usr/sbin/console-kit-daemon
>
> Command htop shows about 50 repetitions, differing only in pid.
> /* Cut & paste from htop under Eterm is not working */
>
> For a less dramatic example,
> [root@jb jim]# ps -eF |grep amarok
> jim 6878 1 2 164695 77348 0 08:46 ? 00:00:58
amarokapp
> jim 6895 6878 0 4397 3316 0 08:46 ? 00:00:00
ruby
> /usr/share/apps/amarok/scripts/score_default/score_default.rb
> root 7552 7292 0 1822 808 1 09:27 pts/2 00:00:00
grep
> --color amarok
>
> htop shows 11 instances of amarokapp, with the cpu% number
> changing every few seconds for about half of them. Similar
> examples for other processes abound.
>
> Is this standard behavior? A bug? My wag is that the process
> #s for the duplicated entries were once used by the process but
> are dead, yet htop is picking them up. If so, why is cpu% time
> being rotated among them?
>
> I am running kernel 2.6.24.4-desktop-1mnb as part of 2008.1 rc2
> on my 64-bit AMD/nForce 410 system, but I fail to see how that
would
> affect this behavior.
>
> Cheers!
>
> jim b.
>
> --
> UNIX is not user-unfriendly; it merely
> expects users to be computer-friendly.

I experienced
the same on openSUSE 11. Many entries for console-kit-daemon, amarok,
...

It turns out that it is actually not different processes, but well all
threads that are run by a single process (ie. all using the same
memory context as the parent process).

If you don't want to see that information anymore, you can configure
htop to hide all userland thread:

Setup menu (F2) --> Display options --> Hide userland threads

And that's it!