Bug 116635 - Inconsistent Output Format in "ps" Command
Inconsistent Output Format in "ps" Command
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: procps (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-23 19:18 EST by ensafi
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 14:51:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description ensafi 2004-02-23 19:18:27 EST
Description of problem:

Running "ps -ef" or any "ps" command containing the username in a 
custom output format of the form "-o ...,user,..." behaves as 
follows: if the username is less than or equal to 8 characters, it 
displays the name; otherwise, it displays the UID number.  While this 
keeps the column formatting nice and neat, it is inconsistent 
behavior and makes it difficult for human operators to decipher who's 
running what process.

At least under one other operating system (Solaris 8) the username is 
always displayed, truncated to 8 characters.  Many Linux commands do 
the same: "top" and "w" truncate the username, and "ls" displays the 
full username, but neither automatically converts long names to UIDs 
by default.
 
I would be perfectly happy if there was an environment variable 
and/or command-line switch to alter this behavior under Linux.  Is 
there already a way to force "ps" to always display usernames?  If 
not, it would be a useful feature.  It doesn't really matter to me 
whether it is modified to behave like Solaris by default, or if is 
implemented as an option, but it would be nice to be able to produce 
a nice, human-readable process listing containing either full or 
truncated usernames.

Version-Release number of selected component (if applicable):

procps-2.0.13-9.2E

How reproducible:

Run "ps -ef" on a system with jobs running as two different users, 
where one username is no more than 8 characters long, and the other 
username is more than 8 characters long.
Comment 1 Daniel Walsh 2004-03-25 15:22:20 EST
Please check against procps-3.1.15.

Dan
Comment 2 ensafi 2004-03-25 15:46:17 EST
No change in procps-3.1.15, still need a fix.

Eskandar
Comment 3 Daniel Walsh 2004-05-28 13:48:07 EDT
Fixed in procps-3.2.1
Comment 4 ensafi 2004-05-28 14:16:01 EDT
Is procps-3.2.1 going to be incorporated into the next release of 
RHEL?  Sounds like a bing leap from procps-2.0.13-9.2E.
Comment 5 Daniel Walsh 2004-05-28 14:24:11 EDT
Yes
Comment 6 Albert Cahalan 2004-07-20 13:30:04 EDT
The UNIX standard required that ps present the username as a
number when it will not otherwise fit in the available space.
Thus, this is not a bug. It's a required feature.

Truncating the name is seriously bad. MichelleRoberts and
MichelleRobertson are different users and must not be confused.
Comment 7 ensafi 2004-07-20 15:10:27 EDT
Not so.  Most UNIX systems display the truncated name.  Most other 
UNIX programs (e.g., top and w) display the trucnated name, and some 
display the full name (e.g., ls).  There is no requirement in UNIX to 
revert to UIDs when names do not fit within a required space.  
However, if this is your belief or your preference, then it should be 
made a user-selectable option.  I think the output field width of the 
user name should also be a user-selectable option, but this is 
another issue.

Reverting to UIDs results in inconsistent output, and it also forces 
people to look up UIDs in case they want to inform other users about 
runaway jobs -- after all, we don't tend to memorize UIDs, but user 
names are easy to remember.  A truncated user name is more useful and 
more easily idenified by most users than a numerical UID.  In some 
rare cases, if the first 8 characters are identical, you might run 
into an ambiguous situation, but the same is true in programs such as 
top and w.

Once again, whether to revert to UIDs should be an option.  The best 
way to conrol it without changing the current behavior would be an 
environment variable and/or a command-line switch.

I also refer you to a bug report for another Linux variant which I 
have never used, but they seem to agree with Solaris and most other 
commercial UNIX versions:

Date: Sun, 22 Apr 2001 23:48:50 -0700
From: Uriah Welcome <precision@devrandom.net>
To: submit@bugs.debian.org
Subject: ps doesn't display usernames > 8 characters.

Package: procps
Version: 2.0.7-4

When you run 'ps u' it doens't display usernames that are longer than 
8 characters.. instead it displays the uid.  I wrote a quick little 
patch to fix this..

   Output currently..

[11:44:45] 503 [~]:harp% ps u
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
1000       303  0.0  0.1  2376  444 tty1     S    09:42   0:00 -bash

   Output after my patch..

[11:45:17] 507 [~/work/procps-2.0.7/ps]:harp% ./ps u
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
precisio   303  0.0  0.1  2376  444 tty1     S    09:42   0:00 -bash

btw, this only happens on testing/unstable.  In potato is exibits the
proper behavoir.
Comment 8 Albert Cahalan 2004-07-20 15:27:46 EDT
Let me quote from The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition, which is the most recent issue
of the combined UNIX and POSIX standard. It's an ISO standard.
Also, UNIX is a registered Trademark of The Open Group
and POSIX is a registered Trademark of The IEEE.

ruser
    The real user ID of the process. This shall be the
    textual user ID, if it can be obtained and the field
    width permits, or a decimal representation otherwise.
user
    The effective user ID of the process. This shall be
    the textual user ID, if it can be obtained and the field
    width permits, or a decimal representation otherwise.

See for yourself:
http://www.opengroup.org/onlinepubs/009695399/toc.htm

If top and w truncate the names, then they are buggy.
(IMHO, since they are not part of the UNIX standard)
Comment 9 ensafi 2004-07-20 15:35:30 EDT
Hmmm... OK, I guess we'll just put a wrapper over ps to accomplish 
what we need.  Thank you for pointing me to this info.
Comment 10 Albert Cahalan 2004-07-20 15:48:08 EDT
I also think the output field width of the user name
should be a user-selectable option, so it is. Note the
column header name and user name that I've chosen.

First, the ugly POSIX standard way. The column width
is adjusted to fit a renamed header.

$ ps -u unwieldiness -opid,user=CumbersomeUserNames -ocomm
 PID CumbersomeUserNames COMMAND
2182 unwieldiness        bash

Second, the friendly Linux way. Just add a number.

$ ps -u unwieldiness -o pid,user:19,comm
 PID USER                COMMAND
2182 unwieldiness        bash
Comment 11 Jason Tibbitts 2004-08-30 09:55:31 EDT
At least procps-3.2.0-1.1 as included with FC2 will truncate long
usernames, but it does it at least for some users it does it oddly.  Note:

> ps aux|grep era
root     26498  0.0  0.2 10440 2840 pts/3    S    08:46   0:00 su -
eramnarine
eramnar  26499  0.0  0.2 10312 2288 pts/3    S    08:46   0:00 -bash
tibbs    26554  0.0  0.0  2704  392 pts/2    S    08:53   0:00 grep era

Note that the user name is "eramnarine" but the user name is truncated
to seven characters.  Why not eight?  Note that the longest user name
currently running a process is eight characters in length and it is
fully displayed.

Note also:

> ps -u eramnarine -o pid,user:8,comm
  PID USER     COMMAND
26499 eramnar  bash

An off-by-one error, perhaps?
Comment 12 Albert Cahalan 2004-09-01 13:26:44 EDT
unwieldiness@cube:/root$ ps -u unwieldiness -o pid,user:8,comm
 PID USER     COMMAND
3721 1001     bash
3732 1001     ps
unwieldiness@cube:/root$ ps --version
procps version 3.2.3
unwieldiness@cube:/root$ ps -u unwieldiness -o pid,user:12,comm
 PID USER         COMMAND
3721 unwieldiness bash
3734 unwieldiness ps
unwieldiness@cube:/root$ ps -u unwieldiness -o pid,user:11,comm
 PID USER        COMMAND
3721 1001        bash
3735 1001        ps

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