Bug 711473 - ps doesn't resolve Active Directory UIDs to User names
Summary: ps doesn't resolve Active Directory UIDs to User names
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: procps
Version: 6.1
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Jaromír Cápík
QA Contact: BaseOS QE - Apps
Depends On:
TreeView+ depends on / blocked
Reported: 2011-06-07 15:14 UTC by Kai Meyer
Modified: 2012-01-11 12:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-01-11 12:49:23 UTC

Attachments (Terms of Use)
/proc/<pid>/environ file for a Bash process (1.39 KB, application/octet-stream)
2011-12-20 19:19 UTC, Kai Meyer
no flags Details
Some proc files for uid kai.meyer (1.49 KB, application/x-gzip)
2012-01-09 22:06 UTC, Kai Meyer
no flags Details

Description Kai Meyer 2011-06-07 15:14:52 UTC
Description of problem:
My RHEL6 workstation is a member of an Active Directory Domain. Domain logins work wonderfully, samba shares use the domain to authenticate, everything is great. It's curious that ps doesn't resolve UIDs for my domain user to my username, but top does.

For example:
[kai.meyer@kai-rhel6 ~]$ top -i -u kai.meyer -c -b1
top - 09:07:03 up 3 days,  7:05,  6 users,  load average: 0.09, 0.13, 0.10
Tasks: 302 total,   1 running, 301 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us,  0.2%sy,  0.3%ni, 98.7%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16456856k total, 15975768k used,   481088k free,   247368k buffers
Swap:  2097144k total,        0k used,  2097144k free, 14076500k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                            
 6746 kai.meye  20   0 17248 1316  864 R  1.9  0.0   0:00.01 top -i -u kai.meyer -c                                                                                                            
[kai.meyer@kai-rhel6 ~]$ ps -fu kai.meyer
16777216  6524     1  0 Jun06 ?        00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login
16777216  6534  2705  0 Jun06 ?        00:00:00 gnome-session
16777216  6543     1  0 Jun06 ?        00:00:00 dbus-launch --sh-syntax --exit-with-session

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

How reproducible:
Join an AD domain, and check ps list.

Steps to Reproduce:
1. Use http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_Authentication.html
2. User Account Database: Winbind
Winbind Domain: <your domain>
Security Model: domain
Winbind Domain Controllers: <your domain controllers>
Template Shell: /bin/bash

3. Join the Domain (Requires Domain Administrator's password).
4. Under Advanced Options:
Check the box for "Create home directories on first login"

In order for Gnome to login, you can't have '\' characters in the username (ie: domain\username) so I fixed it by having winbind use the default domain (we only have one, so it's fine with me). My resulting smb.conf look like this (for authconfig)

   workgroup = #CENSORED#
   password server = #CENSORED#
   security = domain
   idmap uid = 16777216-33554431
   idmap gid = 16777216-33554431
   template shell = /bin/bash
   winbind use default domain = yes
   winbind offline logon = false

Actual results:
The ps command doesn't resolve UIDs to usernames on the windows domain.

Expected results:
The ps command should use a mechanism like top uses to resolve UIDs to usernames.

Additional info:

Comment 2 Jan Görig 2011-06-28 08:56:07 UTC
The top and ps utilities belongs to procps. Moving.

Comment 3 Jaromír Cápík 2011-07-15 15:37:37 UTC
Hello Kai.

Could You please provide me with Version-Release number of the procps where the issue is reproducible?
As Jan Görig noted, top & ps commands belong to the procps package.

Thanks in advance.


Comment 4 Kai Meyer 2011-07-15 19:04:33 UTC
Ya, sorry for the confusion. I'm running:

And I just verified again to make sure than any recent updates fixed the issue. The issue still exists.

Thanks for your attention :)

Comment 5 Jaromír Cápík 2011-08-05 14:55:04 UTC
Hello Kai.

I have an additional question.
Does the ps tool show a correct set of processes? I mean the processes belonging to user kai.meyer ... I'm trying to figure out if it's just about the information displayed in the UID column or if the whole list of processes is incorrect.

Thank You.


Comment 6 Kai Meyer 2011-08-05 15:27:16 UTC
It is just the information displayed in the UID column. The command: 
ps -fu kai.meyer
Displays the correct list of processes, just the same as if I had done:
ps -fu 16777216
But when the output prints, I get a UID instead of a username in the UID column. As far as I can tell, it's simply the output that is incorrect. 

Username -> UID works. UID -> Username does not. This is not the case for the 'top' command, which will filter by username or UID correctly *AND* display the username in the USER column instead of the UID in the USER column.

-Kai Meyer

Comment 8 Jaromír Cápík 2011-12-20 14:54:17 UTC
Hello Kai.

I'm unable to reproduce the issue. Both commands (top & ps) give me the correct username.


-bash-4.1$ id
uid=16777217(jcpokus) gid=16777218(domain users) skupiny=16777218(domain users),16777217(BUILTIN\users),16777222(grupa2),16777223(nase rhev),16777224(grupa4-g) kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


[root@localhost /]# ps -fu jcpokus
jcpokus   3905  3897  2 15:25 ?        00:00:18 sshd: jcpokus@pts/2
jcpokus   3906  3905  0 15:25 pts/2    00:00:00 -bash
jcpokus   4118  3906 99 15:36 pts/2    00:01:23 cat /dev/zero


[root@localhost /]# top -u jcpokus
top - 15:39:18 up  1:09,  3 users,  load average: 0.96, 0.59, 0.29
Tasks: 123 total,   2 running, 121 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.5%us, 49.4%sy,  0.0%ni, 50.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1020692k total,   359996k used,   660696k free,    25804k buffers
Swap:  1048568k total,        0k used,  1048568k free,   194084k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                
 4118 jcpokus   20   0 98.6m  608  492 R 99.7  0.1   2:50.97 cat                                                                                                                    
 3905 jcpokus   20   0  104m 4636 1180 S  0.0  0.5   0:18.09 sshd                                                                                                                   
 3906 jcpokus   20   0  104m 1848 1508 S  0.0  0.2   0:00.05 bash 


Please, update to procps-3.2.8-21.el6 and retest. If it still fails in Your case, then we would have to compare the AD configuration. It's possible, that both tools use a different internal logic and one of them fails due to a failure in one of the dependencies. In such case an update to 6.2 could solve the issue. Please, let me know about Your possibilities / test results.

Thanks in advance.


Comment 9 Kai Meyer 2011-12-20 17:15:03 UTC
Problem still exists for me. I'm open to ideas here. I've only added 'realm = ###' to my smb.conf file since I reported the issue (to fix some unrelated problem I've since forgotten about.)

Thanks for looking into this. Let me know what else I can provide that will help diagnose the problem.

[kai.meyer@kai-rhel6 ShadowBack]$ id
uid=16777216(kai.meyer) gid=16777221(domain users) groups=16777221(domain users),6(disk),16777223(stcdraper),16777224(stcall),16777225(engineering users),16777228(sbs mobile users),16777229(web workplace users),16777305(BUILTIN\users)
[kai.meyer@kai-rhel6 ShadowBack]$ ps -fu kai.meyer | head
16777216  2414     1  0 Dec19 ?        00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login
16777216  2421     1  5 Dec19 ?        01:20:31 /usr/bin/python /usr/share/virt-manager/virt-manager.py
16777216  2426  2405  0 Dec19 ?        00:00:00 gnome-session
16777216  2435     1  0 Dec19 ?        00:00:00 dbus-launch --sh-syntax --exit-with-session
16777216  2436     1  0 Dec19 ?        00:00:09 /bin/dbus-daemon --fork --print-pid 6 --print-address 8 --session
16777216  2522     1  0 Dec19 ?        00:00:09 /usr/libexec/gconfd-2
16777216  2530     1  0 Dec19 ?        00:00:25 /usr/libexec/gnome-settings-daemon
16777216  2534     1  0 Dec19 ?        00:00:00 seahorse-daemon
16777216  2536     1  0 Dec19 ?        00:00:00 /usr/libexec/gvfsd
[kai.meyer@kai-rhel6 ShadowBack]$ top -u kai.meyer -b | head
top - 10:08:36 up 1 day, 34 min, 14 users,  load average: 0.24, 0.18, 0.28
Tasks: 363 total,   2 running, 361 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.3%us,  1.1%sy,  0.2%ni, 93.6%id,  2.7%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  16322852k total, 15970016k used,   352836k free,   169476k buffers
Swap:  2097144k total,      236k used,  2096908k free, 10323752k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                      
 2421 kai.meye  20   0  764m  58m  14m S  9.6  0.4  80:32.04 python                                                                                                                                                       
 2732 kai.meye  20   0  300m  61m  15m S  1.9  0.4  24:16.97 compiz                                                                                                                                                       
 7783 kai.meye  20   0 1239m 366m  47m S  1.9  2.3  11:10.53 firefox                                                                                                                                                      
[kai.meyer@kai-rhel6 ShadowBack]$ rpm -q procps
[kai.meyer@kai-rhel6 ShadowBack]$ rpm -q redhat-release-workstation

Comment 10 Jaromír Cápík 2011-12-20 17:44:15 UTC
The only differences in smb.conf I noticed are these:

security = ads
winbind use default domain = true

there was a change from YES to TRUE ... but it's hard to guess if that could cause any problems ...
NOTE: We used w2k8 in 2k3 mode for the test...

Could You please also do the following?
1.) test "htop"
2.) provide me with output of the following command

   wbinfo --uid-info 16777216

Thanks in advance.

Comment 11 Jaromír Cápík 2011-12-20 18:03:05 UTC
Could You please also pick one of the processes matching the "kai.meyer" username and provide me with the /proc/<PID>/environ file? Just replace the <PID> placeholder with a selected PID ...

Comment 12 Jaromír Cápík 2011-12-20 18:14:53 UTC
I'm mostly interrested in the USER= and LOGNAME= fields if You have problems with sensitive parts of the data ... 

They are both set to "jcpokus" in my case ...

Comment 13 Kai Meyer 2011-12-20 19:19:33 UTC
Created attachment 548933 [details]
/proc/<pid>/environ file for a Bash process

It looks like USER, USERNAME, and LOGNAME all have kai.meyer correctly assigned.

wbinfo --uid-info 16777216

htop appears to work correctly.

Comment 14 Jaromír Cápík 2012-01-09 16:01:26 UTC
This must be really some small detail ... 

Please, repeat that once again, but this time attach the following 4 files from /proc/<PID>/ for the selected pid matching the "kai.meyer" username ... 


Thanks in advance.

Comment 15 Kai Meyer 2012-01-09 22:06:17 UTC
Created attachment 551684 [details]
Some proc files for uid kai.meyer

Here's your requested info. I hope this helps :)

Comment 16 Jaromír Cápík 2012-01-10 15:04:27 UTC
Hello Kai.

Thanks. I'm solving a similar issue, where the reproduction scenario worked in my case. It's possible, that the root cause is common or similar for both issues. I'll let You know once I have any news.


Comment 17 Jaromír Cápík 2012-01-10 17:41:06 UTC
Hello Kai.

I analysed the code deeply and the root cause might be funny.
It's a feature in the 'do_pr_name' function. When the username is too long to fit in the column size, then the user's UID is printed instead of the username.
That's why it worked in my case. My username was shorter than Yours.

Please, let me know if You're happy with this explanation and if it is possible to close this Bug.

Thank You.


Comment 18 Kai Meyer 2012-01-10 19:20:57 UTC
[kai.meyer@kai-rhel6 ShadowBack]$ ps -o user,cmd
16777216 ps -o user,cmd
16777216 -bash
[kai.meyer@kai-rhel6 ShadowBack]$ ps -o user:8,cmd
16777216 ps -o user:8,cmd
16777216 -bash
[kai.meyer@kai-rhel6 ShadowBack]$ ps -o user:9,cmd
kai.meyer ps -o user:9,cmd
kai.meyer -bash

How do you like that :). Thanks so much for the explanation!

Comment 19 Jaromír Cápík 2012-01-11 12:49:23 UTC
Yes, exactly. That's the most funniest thing. It's just 1 character longer than the Active Directory UID.

I understand Your answer as YES -> Closing the bug.

Have a nice day.


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