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.
Please check against procps-3.1.15. Dan
No change in procps-3.1.15, still need a fix. Eskandar
Fixed in procps-3.2.1
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.
Yes
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.
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> To: submit.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.
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)
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.
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
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?
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