Bug 253563 - utmp isn't updated after logging into X, so "who" isn't accurate
Summary: utmp isn't updated after logging into X, so "who" isn't accurate
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gdm
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Ray Strode [halfline]
QA Contact: desktop-bugs@redhat.com
: 430497 (view as bug list)
Depends On:
Blocks: 740538
TreeView+ depends on / blocked
Reported: 2007-08-20 16:28 UTC by Steve Cleveland
Modified: 2018-10-19 19:57 UTC (History)
4 users (show)

Clone Of:
: 740538 (view as bug list)
Last Closed: 2008-05-21 16:01:16 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0398 normal SHIPPED_LIVE gdm bug fix update 2008-05-19 23:09:06 UTC

Description Steve Cleveland 2007-08-20 16:28:26 UTC
Description of problem:

After logging into either KDE or Gnome, it doesn't appear that /var/run/utmp
gets updated with the logged in user.  This keeps apps like 'who' and 'w' from
seeing the users.  I don't know if this actually a gdm problem, but it's as
close as I can get.

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


How reproducible:


Steps to Reproduce:
1. Login to either KDE or Gnome
2. Open a remote SSH connection
3. Run 'who' or 'w'
Actual results:

The user that logged into Gnome or KDE doesn't show up in 'who'

Expected results:

The user that logged into Gnome or KDE should show up in 'who'

Additional info:

In RHEL4, when a user logs into Gnome or KDE (no extra applications running),
'who' would report like this (I'm logged in as root over ssh to generate this):

 09:13:47 up 16 days, 21:30,  2 users,  load average: 0.07, 0.03, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    zen.engr.oregons 09:13    0.00s  0.04s  0.00s w
hardingt :0       -                09:12   ?xdm?  14:17   0.04s -/bin/csh -c
/usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-sessi

in RHEL5, that no longer happens:

 09:17:04 up 37 days, 18:28,  1 user,  load average: 0.04, 0.03, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    zen.engr.oregons 08:52    0.00s  0.12s  0.00s w

If a user then opens a gnome-terminal, for instance, then they show up in 'who'.
 I'm thinking whatever mechanism is supposed to update utmp on login isn't working.

Bug report #244807 is basically the same as this one, but they asked that I open
a new bug report.

Comment 1 Sigurd Mytting 2007-10-01 12:35:23 UTC
I have the same problem, this is an urgent matter for us, it stops upgrade of
about 500 clients to RHEL5.  ("We" are the computer science department at the
largest University in Norway, we're running our own systems for tracking where
users log in, how long they use the terminal etc, using data from utmp.)

After digging into a RHEL4 workstation as well it seems to me that a
sessreg-section in $GDMROOT/PreSession/Default has been removed in RHEL5.  It
doesn't look intentionally since there still is exists a entry to remove the
login in the PostSession/Default-file.

I also see the same problem with xterm (as referenced in bug report #244807).

Comment 2 Ray Strode [halfline] 2007-10-01 14:02:06 UTC
Proposing bug for a future RHEL5 update.

Comment 3 RHEL Product and Program Management 2007-10-16 03:46:36 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 5 Ray Strode [halfline] 2008-01-14 17:23:34 UTC
should be fixed in gdm-2.16.0-36.el5

marking MODIFIED for QA

Comment 7 Ray Strode [halfline] 2008-01-28 14:47:09 UTC
*** Bug 430497 has been marked as a duplicate of this bug. ***

Comment 10 errata-xmlrpc 2008-05-21 16:01:16 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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