7

On a redhat box [ Red Hat Enterprise Linux AS release 4 (Nahant Update 3) ]

Frequently we notice two people being assigned to the same pseudo terminal. For example:

$who am i
user1 pts/4        Dec 29 08:38 (localhost:13.0)
user2 pts/4        Dec 29 09:43 (199.xxx.xxx.xxx)
$who -m
user1 pts/4        Dec 29 08:38 (localhost:13.0)
user2 pts/4        Dec 29 09:43 (199.xxx.xxx.xxx)
$whoami
user2

This causes problems in a script because "who am i" returns two rows. I know there are differences between the two commands, and obviously we can change the script to fix the problem. But it still bothers me that two users are being returned with the same terminal. We suspect it may be related to dead sessions. Can anyone explain why two (non-unique) pts number are being assigned and/or how that can be prevented in the future?

Improve this question

3 Answers 3

Reset to default
1

Have you tried with a more recent version of Red Hat? 4.3 is pretty old, the latest 4.x-release is 4.8. Also, Red Hat 5 is in version 5.4 which is a big step forward. If you like to try a newer version without the hassle of purchasing Red Hat you can try CentOS which is binary compatible with Red Hat.

Improve this answer
1
  • Agreed, but in our corporate environment its more involved than that. We have an upgrade scheduled, but it is still a ways out. We noticed that between different *nix systems that who -m acted different too.
    – bobtheowl2
    Jan 3, 2010 at 1:22
1

The advice to upgrade your server is sound.

Failing that, you can upgrade SOME of the applications and not others. Which components, and just how far to upgrade them, is "left as an exercise for the student".

First you'll want to do some tests to find out what terminal emulator program is being used by people when this happens. Is it Xterm? If so please see the "Red Hat Enterprise Linux 3 Update 8 Release Notes" - http://mirror.centos.org/centos/3/docs/release-notes/as-amd64/RELEASE-NOTES-U8-x86_64-en.html

There you'll find a bug fix for xterm which states simply: "don't write double utmp entry"

So this would lead me to surmise you should probably upgrade xterm to at least xterm-179-6.EL3 (dont ask me why the version number says EL3; I have no idea)

Hope this helps!
-pbr

Improve this answer
4
  • That sounded good, until I saw that we have xterm-192-1. But since the two offending users [ones who shows up on other people's who] uses xterms heavily and I haven't noticed it happening with the rest of the group it still sounds like it could be xterm related.
    – bobtheowl2
    Jan 12, 2010 at 23:22
  • Darn. Though I nailed it for you. Maybe I did; maybe these users are running an xterm thats located in some other 'bin' directory? (I.e. are you sure they're running your SYSTEM's xterm program?) Try this: 'sudo updatedb' (go to lunch) then 'sudo locate xterm|grep bin'. It's not a foolproof way to locate EVERY executable named xterm on your system, but it'll run a LOT faster than the alternative - 'sudo find / -name xterm -executable -print'. Try this last command only if the locate/grep approach doesn't identify any 'rogue' versions of xterm laying around.
    – pbr
    Jan 14, 2010 at 0:04
  • "xterm-179-6.EL3" is probably "Enterprise Linux 3" and may be a more recent version of xterm, or one that has some more specific things necessary for RHEL.
    – Trevoke
    Feb 3, 2010 at 15:52
  • bobtheowl2 - haven't heard back from you - did you search your system to see if there were any other xterm executables installed elsewhere on your system? Just because your primary xterm package is 192-1 doesn't mean there couldn't be older executables in some other directory somewhere.
    – pbr
    Feb 14, 2010 at 11:49
1

I can't reproduce this behaviour here - whatever I do the utmp gets cleaned up - but the utmp updating is done by a helper program utempter, in /usr/lib/utempter, which is called by xterm, so if xterms are being killed stone dead for some reason (such as virtual memory being exhausted) it may be that it doesn't get a chance to clean up.

Note also that a security vulnerability was fixed in it http://rhn.redhat.com/errata/RHSA-2004-174.html though I guess it's unlikely the user in question is causing disfunctions by deliberately exploiting that.

See if you can reproduce the behaviour by launching xterm in the background and killing it without giving it an opportunity to clean up utmp: 

$ who
$ xterm &
[1] 6229
$ who
$ kill -9 6229
$ who

And one voodoo theory: I notice that xterm has a setting to make the utmp behaviour more careful. It is normally enabled by default and disabled by putting 

XTerm*ptyHandshake:     false
in ~/.Xresources or system-wide in /etc/X11/Xresources/xterm. It's unlikely to be that, but just a thought.

One workaround might be to persuade or compel users to use a different X terminal emulator such as rxvt, a smaller drop-in replacement that responds to existing xterm configuration settings, doesn't include the Tektronix 4014 line-drawing graphics emulation feature and uses significantly less memory to run.

Improve this answer
1
  • The users that this happens to are definitely not causing it to be malicious. I haven't been able to reproduce it either. I did notice that even I [only using putty/ssh] had an old utmp entry out there for earlier this week. This coincided with when my vpn connection hiccuped and I had to kill my putty window and reopen. Naturally, I can't reproduce it here today. I wasn't aware of utempter, but that seems like the right direction.
    – bobtheowl2
    Jan 21, 2010 at 15:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .