Bug 1987 - finger has wtmp problems
finger has wtmp problems
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: finger (Show other bugs)
1.0
i386 Linux
low Severity low
: ---
: ---
Assigned To: Crutcher Dunnavant
:
: 3060 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-04-04 16:08 EDT by Jay Freeman
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-04-08 15:12:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Freeman 1999-04-04 16:08:56 EDT
I believe this might be related to my nscd problem which I
posted earlier (bug #1979).  I seem to have various residual
entries in /var/log/wtmp which are logins that got frozen
and then didn't log out properly.  w pays no leave of these,
and lists correct information.  finger however attempts to
show information on these logins, and then has extra
problems because the terminal's don't exist in the pts
filesystem because they were unallocated.  It brings up a
couple complaint errors about missing files then continues,
marking the messed up files with a * right before the Tty
listing.

[root(2)@ironclad c7]# w
  2:37pm  up 23:08,  5 users,  load average: 0.00, 0.04,
0.02
USER     TTY      FROM              LOGIN@   IDLE   JCPU
PCPU  WHAT
saurik   pts/4    saurik           Sat 6pm 16.00s  0.51s
0.07s  screen -r
saurik   pts/5    saurik           Sat 6pm  9:39  13.09s
0.06s  vi ftpaccess
saurik   pts/6    saurik           Sat 7pm  0.00s  2.45s
0.18s  w
[root(2)@ironclad c7]# finger
finger: /dev//pts/1: No such file or directory
finger: /dev//pts/3: No such file or directory
Login     Name         Tty  Idle  Login Time   Office
Office Phone
saurik    Jay Freeman  *pt        Apr  3 15:50 (saurik)
saurik    Jay Freeman  *pt        Apr  3 17:20 (saurik)
saurik    Jay Freeman   pt        Apr  3 18:29 (saurik)
saurik    Jay Freeman   pt        Apr  3 18:32 (saurik)
saurik    Jay Freeman   pt        Apr  3 19:59 (saurik)
Comment 1 Jeff Johnson 1999-04-04 16:17:59 EDT
Can you make sure that you are running util-linux-2.9o? There's
a fix in login to get the tty slot correct on network connections.
(before I go wtmp diving :-) You might also look at utmpdump ...
Comment 2 Jay Freeman 1999-04-04 16:22:59 EDT
[root(5)@ironclad /etc]# utmpdump
Utmp dump of /var/run/utmp
[root(5)@ironclad /etc]# rpm -q util-linux
util-linux-2.9o-6
# Couldn't find a manual page for utmpdump or even its binary (and it
isn't in bash's man page) :(.
Comment 3 Jay Freeman 1999-04-04 16:36:59 EDT
Ok, I think I figured out how this would be used, these three lines
were right after each other:
[7] [03377] [/1  ] [saurik  ] [pts/1       ] [Apr  3 15:50:47]
[7] [05982] [/3  ] [saurik  ] [pts/3       ] [Apr  3 17:12:14]
[7] [06477] [/3  ] [saurik  ] [pts/3       ] [Apr  3 17:20:26]
Note the lack of a logout for 05982 right before the login of 06477 on
the same terminal.  I know that this isn't from nscd because I stopped
using nscd at 14:40 (checked my logs from IRC where I mentioned the
problem).
Comment 4 Jay Freeman 1999-04-04 16:52:59 EDT
I just tried logging out of one of the terminals that I had open that
was valid, and it was not logged either (and is now showing up with
finger).  After examining the utmpdump of wtmp and checking my syslog
I got:

[root(6)@ironclad log]# tail messages -n 4
Apr  4 15:49:13 ironclad PAM_pwdb[10837]: (login) session closed for
user saurik
Apr  4 15:49:39 ironclad PAM_pwdb[23667]: (login) session opened for
user saurik by saurik(uid=0)
Apr  4 15:49:39 ironclad pam_console[23667]: did not find console 1
Apr  4 15:49:39 ironclad  -- saurik
[23667]: LOGIN ON 1 BY saurik FROM saurik
[root(6)@ironclad log]# utmpdump wtmp | tail -n 2
[5] [21786] [pu  ] [        ] [            ] [Apr  4 10:55:19]
[7] [23667] [/1  ] [saurik  ] [pts/1       ] [Apr  4 15:49:39]
Comment 5 jjdenhup 1999-04-07 02:36:59 EDT
"who" shows the same problems...
Comment 6 Jeff Johnson 1999-04-08 15:12:59 EDT
The problem here is that there are several packages that need to
interact in order to get finger info correct.

First, utmpdump can be used to display a wtmp like file such
as /var/run/utmp, /var/run/utmpx, and /var/log/wtmp.
A first field of [7] indicates a USER_PROCESS, while an [8]
indicates a DEAD_PROCESS (i.e. logged off). See entries
of the same name in /usr/include/bits/utmp.h for the complete
list.

Second, the utmp entries are mainly written by login (for
login, rlogin, and telnet) or from a package called utempter (for
xterm, screen, possibly others). The records are often accessed
by a legacy field that utempter was not setting correctly, so
you need to upgrade to (at least) utempter-0.5-1.

Thirdly, much code like finger (and possibly who) is going to
break because of new names for pseudo tty devices. The old
names looked like ttypX (with id "pX") while new names look
like pts/X (with id "/X"). This has been (at least partially) fixed
in finger-0.10-24.

Lastly, there is the likelihood that, with all these component
changes, that you will have broken utmp entries lying around.
Doing
	cp /dev/null /var/run/utmp
	cp /dev/null /var/run/utmpx
	cp /dev/null /var/log/wtmp	(probably not necessary).
and rebooting is necessary to eliminate bogus entries.

Please reopen this bug if you have further problems.
Comment 7 Jeff Johnson 1999-07-28 11:33:59 EDT
*** Bug 3060 has been marked as a duplicate of this bug. ***

`finger` prints "/<num>" as the user's tty (if on a pty,
that is), instead of "pts/<num>" (on 2.2 kernels with
"Unix98 PTY" support, which 6.0 ships with). Not much of a
bug, but somewhat lame.

A patch for this can be found at:
http://async.org/~ysyi/rh6finger.pts.diff

if you're so inclined to fix it...

------- Additional Comments From jbj@redhat.com  06/02/99 08:10 -------
Could you reply to this message with patch attached? I can't seem
to access the URL.

Thanks.

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