finger shows logged in to console (tty1), even after logging out

diskoe · 01-22-2007, 07:42 PM

Details:
Slack 11
Full Install, selected the 2.4.33.3 (bare.i) kernel with kernel headers, source, modules.
After 1st boot, installed the 2.6.18 (from /testing) generic kernel, source, modules.
Did the mkinitrd, etc...

The system works fine, but I noticed this.

If I login to the console and then logout of the console (doesn't matter how long I stay logged in), the finger command still shows I'm logged in. I'm running the finger command from a ssh session via another computer on the network. I see two login sessions, one on pts/0, which is my ssh session and my self on tty1. But I've logged out of the tty1 console session.

I've ruled out corrupt /var/log/wtmp, /var/log/btmp, /var/run/utmp as I made a root cron to rotate it when nobody is logged into the system. It still shows the above logged in status with finger.

Strange thing is the "who" command shows thing correctly! In the above scenario, I would only see my ssh (pts/0) session and not the tty1 session.

Anyone seen this on their Slack 11 box?

Michielvw · 01-23-2007, 01:45 PM

I might have seen similar behaviour on my box (which runs the 2.6.13.17 kernel from extra/)

if you type in "last" what do you get?

I have last shown this on most occasions with `phantom users`

Code:

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

I quite would like to have at least a clue what is causing this .. or even better how to fix it

diskoe · 01-23-2007, 02:15 PM

Yep, my "last" is just like yours. It shows "gone - no logout" and finger shows the user as logged in.

Do you boot into run-level 4 (graphical login) or do you stay with run-level 3, the text login screen? I use run-level 3. I'm not sure if that makes a difference or not.

Michielvw · 01-23-2007, 02:30 PM

I've seen it mostly happen in runlevel 3. I think a couple of times in runlevel 4 where I switched back to the consoles for one reason or another.

So it would seem more to do with tty[1-10] that gives the problem that the runlevel itself.

Michielvw · 02-04-2007, 09:43 AM

well after some looking around, it seems that it is caused by the /var/run/utmp not properly dealing with logouts on the TTY's (but how/why is still a big question)

I wrote the following script based on information in /etc/rc.d/rc.S:

Code:

#!/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

This does the job, although perhaps a little bit to good. The result is, that your system shows 0 users logged in. So for your users to register ,they need to log-in again.

I am well aware that this is a slightly fugly and dirty way to do it. But for now it does the job in a roudabout way.

diskoe · 02-04-2007, 09:12 PM

I did something similar to you. But I ran the script via a root crontab job while no one is logged in.

Thing is, the problem comes right back after a user logs in and out of console.

Michielvw · 02-05-2007, 08:12 AM

yep, like I said, it is a really bad/fugly/dirty way to do it. It hardly solves the problem and its rathe solution orientated. For now, it's back to the drawing board.

mvandal · 04-26-2007, 06:07 PM

I got the same problem here...I'm running slackware 11.0 with kernel 2.6.19 but I noticed that I have the problem with test26.s kernel provided with Slackware also.

Any developments on this issue??

Thanks!

Michielvw · 05-08-2007, 01:34 PM

Nope, sadly I haven't gotten time to dig around where this problem really is coming from. As far as I can tell it's something with /var/log/utmp not dealing all to well with a 2.6 kernel for various reasons (whatever the heck they may be).

I have also noticed it on -current (2.6.21) systems. I need to have some time and see if I can pinpoint where it comes from. Or ask someone who is a heck of a lot better at this kind of debugging :@)

klunki · 05-12-2007, 02:07 PM

I am still running Slackware 10.2 with a self-compiled 2.6 kernel, and I have the same problem.

After playing around a little bit, I noticed something interesting:
After a reboot and a login/logout on tty2, "who" showed me as logged in on tty2 although I was only logged in on tty1:

Code:

$ who
klunki   tty1         May 12 18:36
klunki   tty2         May 12 18:36

utmpdump showed the following output (hostname, ip and date removed for readability):

Code:

$ utmpdump /var/run/utmp
Utmp dump of /var/run/utmp
[8] [04449] [si  ] [        ] [            ]
[2] [00000] [~~  ] [reboot  ] [~           ]
[1] [20019] [~~  ] [runlevel] [~           ]
[8] [06725] [rc  ] [        ] [            ]
[7] [10093] [c1  ] [klunki  ] [tty1        ]
[7] [10094] [2   ] [klunki  ] [tty2        ]
[6] [10605] [c2  ] [LOGIN   ] [tty2        ]
[6] [10107] [3   ] [LOGIN   ] [tty3        ]
[5] [10107] [c3  ] [        ] [            ]
[6] [10120] [4   ] [LOGIN   ] [tty4        ]
[5] [10120] [c4  ] [        ] [            ]
[6] [10122] [5   ] [LOGIN   ] [tty5        ]
[5] [10122] [c5  ] [        ] [            ]
[6] [10123] [c6  ] [LOGIN   ] [tty6        ]

As you can see there are two entries for the ttys 2, 3, 4 and 5 each one with different ids (for example c3 and 3). And I noticed the wrong order of the entries: the INIT_PROCESS entry for tty3 (with id c3) was written after the LOGIN_PROCESS entry (with id 3). According to the utmp man page (as well as the source of agetty which I have checked), agetty looks for an existing utmp entry by pid. But obviously no entry existed when agetty was started on tty2, 3, 4 and 5 and thus it created a new one with the id derived from the tty name. So I finally found the problem in the sources for "init":

Code:

case RESPAWN:
	ch->flags |= RUNNING;
	if (spawn(ch, &(ch->pid)) < 0) break;
	/*
	 *	Do NOT log if process field starts with '+'
	 *	FIXME: that's for compatibility with *very*
	 *	old getties - probably it can be taken out.
	 */
	if (ch->process[0] != '+')
		write_utmp_wtmp("", ch->id, ch->pid,
			INIT_PROCESS, "");
	break;

Obviously utmp and wtmp are updated after the agetty process is spawned, leading to a race condition. Because the execution order is unspecified, sometimes utmp gets updated properly and sometimes not.

To fix this problem you can simply change the ids in /etc/inittab from "c1" to "1" and so on, but this will not eliminate all the problems, since "init" will sometimes end up overwriting LOGIN_PROCESS entries, resulting in terminals sometimes being shown as tty1 and sometimes as vc/1.
The only real solution would be to patch init and fix the race condition. I have not yet thought about how to do this. (Maybe a little bit of sleep before the execvp call will be sufficient. I have not tested this yet though.)

I hope this helps
Cheers,
klunki

PS: not bad for my very first post, huh?

Alien_Hominid · 05-12-2007, 02:55 PM

Quote:

Originally Posted by klunki

PS: not bad for my very first post, huh?

Hello!
Say that you started to use Linux today.

Michielvw · 05-12-2007, 03:01 PM

Whow. That is actually quite a good post and in fact, I think you got our whole bunch probably quite a bit closer to even solving what is causing this.

klunki · 05-15-2007, 02:13 PM

I think I've fixed the problem now. Its a very simple solution, although it requires recompiling "init". Basically I have just delayed any processes spawned by init for 50ms. This is enough for init to write the utmp entry. I have only tested it on my system, and I am not 100% sure that it will work for you and you should always have a rescue disk ready. Also, the instructions below are for slackware 10.2 so they may slightly differ for 11.0

First unpack the source code of the "sysvinit" package, which can be found in the source/a/sysvinit subdir of your slackware cd/dvd. Then apply the patch sysvinit.diff.gz.

Code:

$ cd /usr/src
$ tar xzf /path/to/cdrom/source/a/sysvinit/sysvinit-2.84.tar.gz
$ cd sysvinit-2.84
$ zcat /path/to/cdrom/source/a/sysvinit/sysvinit.diff.gz | patch -p1

Now copy the patch below into the file "sysvinit.patch" and apply it with "patch -p1 -i sysvinit.patch":

Code:

diff -ur a/src/Makefile b/src/Makefile
--- a/src/Makefile	2007-05-15 20:12:12.000000000 +0200
+++ b/src/Makefile	2007-05-15 20:12:45.000000000 +0200
@@ -11,7 +11,7 @@
 CC	= cc
 CFLAGS	= -Wall -O2 -D_GNU_SOURCE
 LDFLAGS	= -s
-STATIC	=
+STATIC	= -static
 
 # For Debian we do not build all programs, otherwise we do.
 ifeq ($(DEBIAN),)
diff -ur a/src/init.c b/src/init.c
--- a/src/init.c	2007-05-15 20:09:30.000000000 +0200
+++ b/src/init.c	2007-05-14 19:50:01.000000000 +0200
@@ -991,6 +991,7 @@
 
   		/* Reset all the signals */
   		for(f = 1; f < NSIG; f++) SETSIG(sa, f, SIG_DFL, SA_RESTART);
+		usleep(50000);
   		execvp(args[1], args + 1);
 
 		/*

Finally compile and install the new init (and don't forget to backup the old one):

Code:

$ cd src
$ make
$ strip init
$ su
# cp /sbin/init /sbin/init.old
# cat init > /sbin/init

Now reboot and check the result. If something goes wrong and the computer won't boot, use the rescue disk to restore init from the backup.

Michielvw · 05-15-2007, 02:40 PM

Great, I shall test this immediatly

Alien_Hominid · 05-15-2007, 03:35 PM

Great that such things like patches show in this forum. I have always thought (and still thinking) that such distro's as Slackware forum should be full of tweaks (because users are experienced so they know what they do).