Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJaroslav Kortus
2016-04-06 15:36:28 UTC
Description of problem:
ps auxfw does not resolve all UIDs to usernames. In my output it looks like this:
[root@virt-014 ~]# ps auxfw | grep -E '^[0-9]'
68 1503 0.0 0.3 37852 3728 ? Ssl Apr04 0:01 hald
68 1546 0.0 0.1 18008 1108 ? S Apr04 0:00 \_ hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
189 11541 0.1 1.3 98076 13676 ? Ss Apr04 3:14 \_ /usr/libexec/pacemaker/cib
189 11544 0.0 0.3 85504 3728 ? Ss Apr04 0:23 \_ /usr/libexec/pacemaker/attrd
189 11545 0.0 0.2 80944 2840 ? Ss Apr04 0:22 \_ /usr/libexec/pacemaker/pengine
[root@virt-014 ~]# grep 68 /etc/passwd
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
[root@virt-014 ~]# grep 189 /etc/passwd
hacluster:x:189:189:cluster user:/home/hacluster:/sbin/nologin
[root@virt-014 ~]# id hacluster
uid=189(hacluster) gid=189(haclient) groups=189(haclient)
[root@virt-014 ~]# id haldaemon
uid=68(haldaemon) gid=68(haldaemon) groups=68(haldaemon)
Version-Release number of selected component (if applicable):
procps-3.2.8-36.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1. ps auxfw and look for numbers in the first column
2.
3.
Actual results:
numbers appear occasionally instead of usernames
Expected results:
usernames, no numbers as long as the user is "resolvable"
Additional info:
I was able to reproduce this issue on RHEL6, but not on RHEL7 nor Fedora 23. I will investigate this. If this shows up as RHEL6-only issue, I will not propose this to upstream.
The explanation is this:
In RHEL6 version of ps, the "effective user name" field is 8 chars long. As 'haldaemon' retrieved from passwd exceeds this limitation, it is, like in any other such cases, substituted with EUID (68 in this case).
In RHEL7 procps (massively rewritten), the name of effective user is shortened and appended with '+' to fit the field. In this case it would look 'haldaem+'.
A note is present in manual page of ps, section STANDARD FORMAT SPECIFIERS, item 'euser', describing this behavior.
Change to RHEL7-like behavior would bring a risk that other users' scripts depending on this might break.