Linux `Ghost` User

The Case of the Ghost Users.

This case is also discussed at LinuxQuestions.org – Slackware Forum

The situation: You take one Slackware 11.0 system, patched and all, installed with the 2.6.17.13 default kernel. You boot the system and everything humms happily around. You log in and out and do your usual works until, at some point you check logged in users and other various userthings and you see the following output:

output of /usr/bin/last:

root tty2 Thu Jan 18 18:50 gone - no logout
bp pts/3 :pts/2:S.0 Sat Jan 20 22:33 still logged in

Now I know that root is no longer logged in on TTY2 as I am typing this at the machine and switching to tty2 shows me the normal standard login screen. Neither using ^D, exit, logout does seem to make any difference in this case. The box shows the login prompt as normal, yet it seems the system thinks the user just wandered off for a bit of lunch almost.

output of /usr/bin/w:

14:01:44 up 16 days, 12:14, 3 users, load average: 0.35, 0.31, 0.28
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
michiel :0 - Tue10 ?xdm? 2:08m 0.30s /bin/sh /opt/kde/bin
michiel pts/3 :pts/2:S.0 02:00 23:36 1:42 1:42 irssi -!

So here we see the first sign that something is not up to scratch.Three users? I can see two. myself logged in to the KDE desktop Enviroment. and my screen session with all it’s irssi goodness.

output of /usr/bin/finger:

Login Name Tty Idle Login Time Office Office Phone
michiel Michiel *:0 Jan 30 10:21
michiel Michiel pts/3 28 Feb 4 02:00 (:pts/2:S.0)
root tty1 5d Jan 30 10:19

Right, there is root logged into TTY1!!! Now howver if root was really logged in. Shouldn’t therebe a bash shall running?

[root@whitestar]:[~]# ps aux | grep tty1
root 2410 0.0 0.0 1596 152 tty10 Ss+ Jan19 0:00 /sbin/agetty 38400 tty10 linux
root 28595 1.3 28.0 341196 108136 tty11 SLs+ Jan30 96:48 /usr/X11R6/bin/X -br -nolisten tcp :0 vt11 -auth /var/run/xauth/A:0-3iJeXy

As we can see, there are no processes listed for tty1! So how does this compare to an actual root login??

[root@starfury]:[~]# ps aux | grep tty2
root 9999 0.0 2.2 5488 4360 tty2 Ss+ 01:56 0:01 -bash

So as we clearly can see, If root is actually physically logged in on a TTY we will see some kind of shell (on these systems, bash is the default shell for root) , as a representative of the login session. However none is being shown. Yet w/finger seems to agree there is a user logged in.

The problem is that this keeps happening and users keep adding up. Which is kinda annoying and gives a distorted view.

Other observations:

  • This happends mostly in runlevel 3 (runlevel 4 occasionally as well, but the chance that I need to use a TTY instead of a Terminal on runlevel 4 is small.
  • It only happends with actual physical logins on the box. In other words; it doesn’t happen with “su -” or with ssh logins.
  • This behaviour seems only to happen on 2.6 kernels. Before this box was running a 2.4 kernel and I have not seen this behaviour.

Conclusions:
I am starting to lean more and more to the conclusion that something in /var/log/utmp or /var/log/wtmp is seriously borked, and at current I am not sure on how to fix this. The utmp/wtmp theory is kind of supported by the fact that rebooting a box actually fix this problem for a short time (yes, I am aware that rebooting can fix more than one problem)

I am leaning more to the fact now that it is probably the /var/run/utmp rather than the /var/log/wtmp that causes the problem. /var/log/wtmp got recycled recently and that doesn’t seem to have stopped the problem.

Dirty/Fugly Hack: It is possible to reset the whole of the /var/run/utmp in one go. I did it with the following script (based on /etc/rc.d/rc.S)

#!/bin/sh

# Reset /var/log/utmp settings on the fly:
/bin/rm -f /var/run/utmp

# Create a fresh utmp file:
touch /var/run/utmp
chown root:utmp /var/run/utmp
chmod 664 /var/run/utmp

exit 0

However the downside is: It means that all users login states are wiped from the system. Now if the system is used mostly exclusively by just one person, than it is not much of a problem. However for a company server with multiple logins, this could be highly undesirable. And of course, this doesn’t explain why /var/run/utmp has trouble dealing with logged out TTY sessions at all.

Solution: None at the moment

  1. No comments yet.
  1. No trackbacks yet.