Frequently Asked Questions about procps

Why does "ps -aux" complain?

According to the POSIX and UNIX standards, the above command asks to display 
all processes with a TTY (generally the commands users are running) plus all 
processes owned by a user named "x". If that user doesn't exist, then ps will
assume you really meant "ps aux". The warning is given to gently break you
of a habit that will cause you trouble if a user named "x" were created.

What systems are supported?

Linux 2.2.xx, 2.4.xx, and 2.6.xx are commonly tested and expected to work well.
SMP is well supported. Multi-node cluster views require a multi-node /proc 
filesystem; without that you will see a single-node view.

Where to I send bug reports?

You may use the Debian bug tracking system or send your report to 
procps-feedback@lists.sf.net instead.

Why are there so many procps projects?

The original maintainer seems to have had little time for procps. Whatever his 
reasons, the project didn't get maintained. Starting in 1997, Albert Cahalan 
wrote a new ps program for the package. For the next few years, Albert quietly 
helped the Debian package maintainer fix bugs. In 2001, Rik van Riel decided 
to do something about what appeared to be the lack of a maintainer. He picked 
up the buggy old code in Red Hat's CVS and started adding patches. Meanwhile, 
other people have patched procps in a great many ways. In 2002, Albert moved 
procps to this site. This was done to ensure that years of testing and bug 
fixes would not be lost. The major version number was changed to 3, partly to 
avoid confusing users and partly because the top program has been redone.

Why does ps get signal 17?

No ps release has ever had this problem. Most likely your system has been 
broken into. You might want to install a more recent version of the OS. If 
you'd rather take your chances, simply upgrade procps.

Why do ps and top show threads individually?

The 2.4.xx kernel does not provide proper support for grouping threads by 
process. Hacks exist to group them anyway, but such hacks will falsely group 
similar tasks and will fail to group tasks due to race conditions. The hacks 
are also slow. As none of this is acceptable in a critical system tool, task 
grouping is not currently available for the 2.4.xx kernel. The 2.6.xx kernel 
allows for proper thread grouping and reporting. To take advantage of this, 
your programs must use a threading library that features the CLONE_THREAD flag.
The NPTL pthreads provided by recent glibc releases use CLONE_THREAD. 
