Bug 217198 - gdm no longer registering login session with wtmp and utmp
gdm no longer registering login session with wtmp and utmp
Status: CLOSED DUPLICATE of bug 209537
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-24 20:27 EST by Jason Farrell
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-25 00:08:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jason Farrell 2006-11-24 20:27:49 EST
Description of problem:
gdm is no longer registering logins with /var/run/utmp & /var/log/wtmp, so utils
such as "w", "who", and "finger", fail to find the logged in gdm user, and some
scripts are failing. This worked in FC5 and previous.

Steps to Reproduce:
1. log in to X using gdm
2. run "w" from any terminal.
  
Actual results:
No users are shown as logged in.

Expected results:
Old behavior of showing the X user logged in. For example:
 20:26:39 up  2:52,  2 users,  load average: 1.26, 1.22, 1.21
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
jaf      :0       localhost        19:56   ?xdm?   2:57m  0.34s /bin/bash


Additional info:
The source of the problem seems to be because "sessreg" is no longer being
called from "/etc/gdm/PreSession/Default" to register the session, as it's been
removed (intentionally?):

[jaf@nano:0j:170h PreSession]$ diff /etc/gdm/PreSession/Default
/safe5/FC5-backups/etc/gdm/PreSession/Default
70a71,83
>
> SESSREG=`gdmwhich sessreg`
> if [ "x$SESSREG" != "x" ] ; then
>       # some output for easy debugging
>       echo "$0: Registering your session with wtmp and utmp"
>       echo "$0: running: $SESSREG -a -w /var/log/wtmp -u /var/run/utmp -x
\"$X_SERVERS\" -h \"$REMOTE_HOST\" -l \"$DISPLAY\" \"$USER\""
>
>       exec "$SESSREG" -a -w /var/log/wtmp -u /var/run/utmp -x "$X_SERVERS" -h
"$REMOTE_HOST" -l "$DISPLAY" "$USER"
>       # this is not reached
> fi
>
> # some output for easy debugging
> echo "$0: could not find the sessreg utility, cannot update wtmp and utmp"
 
 
[jaf@nano:0j:155h PreSession]$ w
 19:55:12 up  2:20,  1 user,  load average: 1.17, 1.21, 1.24
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1     -                18:46    1:08m  0.08s  0.08s -bash
 
[jaf@nano:0j:162h PreSession]$ sudo sessreg -a -w /var/log/wtmp -u /var/run/utmp
-x /etc/X11/xdm/Xservers -h localhost -l ":0" jaf
[jaf@nano:0j:163h PreSession]$ w
 19:56:05 up  2:21,  2 users,  load average: 1.21, 1.21, 1.23
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1     -                18:46    1:09m  0.08s  0.08s -bash
jaf      :0       localhost        19:56   ?xdm?   2:25m  0.29s /bin/bash
Comment 1 Paul 2006-11-24 20:37:21 EST
same problem here.

I checked the SRPM for gdm-2.16.0-18.fc6, and I found that the
config/PreSession.in file DOES contain the block:

> SESSREG=`gdmwhich sessreg`
> if [ "x$SESSREG" != "x" ] ; then
>       # some output for easy debugging
>       echo "$0: Registering your session with wtmp and utmp"
>       echo "$0: running: $SESSREG -a -w /var/log/wtmp -u /var/run/utmp -x
\"$X_SERVERS\" -h \"$REMOTE_HOST\" -l \"$DISPLAY\" \"$USER\""
>
>       exec "$SESSREG" -a -w /var/log/wtmp -u /var/run/utmp -x "$X_SERVERS" -h
"$REMOTE_HOST" -l "$DISPLAY" "$USER"
>       # this is not reached
> fi
>
> # some output for easy debugging
> echo "$0: could not find the sessreg utility, cannot update wtmp and utmp"

BUT, my copy of /etc/gdm/PreSession/Default does NOT contain that code, even after:

rpm -Uvh --force gdm-2.16.0-18.fc6.i386.rpm

With finger not working, many scrips I have that replied on it are broke.
Comment 2 Ray Strode [halfline] 2006-11-25 00:08:29 EST

*** This bug has been marked as a duplicate of 209537 ***

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