Bug 114012 - procps3 regressions
Summary: procps3 regressions
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: procps
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-21 13:42 UTC by Alexander Larsson
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-27 15:01:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexander Larsson 2004-01-21 13:42:26 UTC
In the upgrade to procps3 we regressed on a couple of places in the
interface. These need to be fixed:

slabtop: 
Need to add this from procps2

free: 
use nicer help output from procps2
add -l and -c options

pmap:
add stack detection from procps2
The output for permissions and header/footer differs. procps3 looks
like solaris pmap, so maybe we should keep that. OTOH the headers in
procps2 are useful.
add -d -q -h/--help -V options from procps2
use nicer help output from procps2

vmstat:
Add gnu-style aliases --noheaders=-n, --active=-a, --version=-V
add --kb, --mb, --gb options (the -k,-m,-g ones don't work, because -m
is something else in procps3)
usage output doesn't list all flags

top:
add -q option
add support for showing threads on key 'H'

Comment 1 Stephen Smalley 2004-01-21 17:37:04 UTC
ps:
For SELinux, treat -Z identically to --context for displaying process
security contexts.

Comment 2 Alexander Larsson 2004-02-05 10:37:09 UTC
Mass reassign to new owner

Comment 3 Alexander Larsson 2004-02-05 10:38:30 UTC
Mass reassign to new owner

Comment 4 Alexander Larsson 2004-02-05 10:40:13 UTC
Mass reassign to new owner

Comment 5 Alexander Larsson 2004-02-05 10:40:52 UTC
Mass reassign to new owner

Comment 6 Daniel Walsh 2004-03-29 12:57:28 UTC
Comments from upstream:


Most of this has been fixed. The one big item left
is an "H" command for top.


Comment 7 Peter Smith 2004-11-22 17:30:02 UTC
ps: 
"forest" and "thread" displays now conflict; these work in AS3 and RH9.


Comment 8 Karel Zak 2004-11-22 18:20:05 UTC
Peter, can you explain it?

Comment 9 Peter Smith 2004-11-23 15:37:21 UTC
On RH9 I can do "ps fm" and get the following.

  PID TTY      STAT   TIME COMMAND
19209 pts/0    S      0:00 su -
19213 pts/0    S      0:00 -bash
19253 pts/0    R      0:00  \_ ps fm

On AS3 I can do "ps fm" and get the following.

  PID TTY      STAT   TIME COMMAND
 5380 pts/0    S      0:00 su -
 5384 pts/0    S      0:01 -bash
21431 pts/0    R      0:00  \_ ps fm

On FC3 if I do "ps fm", I get the following.

ERROR: Thread display conflicts with forest display.
********* simple selection *********  ********* selection by list
*********
-A all processes                      -C by command name
-N negate selection                   -G by real group ID (supports names)
<snip>

On Linux I've almost always used "ps auxfwwwwwwm" which has worked
well for me.  However, this is not possible anymore.


Comment 10 Karel Zak 2004-11-23 17:25:02 UTC
Last version where you can found support for "ps fm" is 2.0.17 (which
is in FC1, RHEL-3). In all new versions is it unsupported. In FC3 is
version 3.2.3.

I don't think we want to change it. There is not guaranty that RHEL-3
will 100% compatible with RHEL-4 or FC-3.


Comment 11 Albert Cahalan 2005-01-05 19:43:44 UTC
This is an unworkable combination of flags.

If you just want to see the threading structure of non-NPTL
threaded apps, simply drop the "m" flag.

If you just want to see all CPU usage, note that a recent kernel
(2.6.10+) will sum up the per-thread data into the process. So
again, drop the "m" option.

If you really want to see the threading structure of NPTL apps,
then sorry, you're out of luck. The kernel does not provide this
information anymore.

If you want to see the process tree and the threads (but not the
threading structure -- not the thread tree of an NPTL app) then
you are also out of luck. This is for at least 3 reasons: it is
complex to implement, it is not commonly desired or generally
useful AFAIK, and the exact behavior (what do do with the ASCII-art)
is not obvious.



Note You need to log in before you can comment on or make changes to this bug.