Greetings,
Thanks to all the people who replied! Many people mailed me saying they have
the same problem and have no solution, some people said they have scripts or
programs to clear out the /etc/utmp file and this seems to solve the problem;
one user said that it's a problem that is only solvable by rebooting the
machine :), and one user said he logs everyone off his system and removes
the existing utmp file to fix the problem.
The consensus seems to be that this is a harmless problem, and the easiest,
most hassle-free way to solve it is to telnet,rsh, or rlogin into the system
until there are enough logins to over-write the tty that still shows up in
the who or w command. It seems that it's best to just leave it alone, though,
since it doesn't seem to be causing any major problems. I would assume,
though, that on systems that run accounting, it would be a hassle to keep tabs
on a tty that still says there's a user logged in, idle for 15 days...
If anyone is interested, I got at least 3 different programs that claim they
fix the problem. One of them seems to work through cron. If you want copies,
e-mail me (meystel@impaqt.drexel.edu), and I'll either send you a copy or
put them up for anonymous-ftp on my machine.
Thanks again,
Mike
-----
Michael A. Meystel
Manager, Operations
IMPAQT Center
Drexel University, Philadelphia, PA U.S.A.
(215) 895-5807 / meystel@impaqt.drexel.edu / meystma@duvm.ocs.drexel.edu
Most of the actual replies are below.
---I have a simple program/script that I use to clear out these ports on a regular basis via cron.
---
I get this problem with users who run X clients with the server on their PCs. They are still logged on according to who, but not accrding to ps.
---
This is normal for exiting OpenWindows or for any abnormal death of a login process. The entries in /etc/utmp are not removed (and that is what w and who used (finger goes thru the process table and so is not affected by this). I have heard of programs which will mess with /etc/utmp (I used to have one myself), but they break at system upgrades if the /etc/utmp structure is changed. I just ignore the results of w and who and use finger...
---
Don't worry! It's a known problem, solved only after reboot.
---
I've never encountered your particular problem before (not using OW myself), but it seems like for some reason a process is leaving an incorrect entry in the utmp file. I have a program I picked up a while back that lets you safely edit your utmp file. Write me if you'd like a copy.
---
we have the same problem here as well, It is caused by bad entries in the /etc/utmp file. One of my buddies wrote up a little program to go in and periodically clean up the this file removing any old entries. We run it hourly with cron. Enjoy
---
Just run rlogin to the system, it will use the pty and update the entry. Annoying, but harmless.
---
I to have this problem, the way I have been ``fixing'' it is by getting everyone logged off the workstation and then removing /etc/utmp and replacing it with an emtpy file. I don't think that this method is very satisfactory, please let me know if you find a better way. I have talked to the sun support people about the problem but because I cannot be specific about the method of causing the problem they do not seem moved to do anything about it.
---
I have exactly the same problem! Please do let me know if you find a nice solution. What I do is to run a small shell script manually which clears out the utmp file for users with no processes. Not very nice, I know.
---
This also happens with SunView. The shelltool or cmdtool makes an entry in /etc/utmp when it starts, and the entry does not always get removed when the tool teminates.
I had a script which broke because of this, which I fixed by checking whether the named terminal still belongs to the named user. (This particular script happens to use "who" instead of "w", but I imagine the same approach would still apply.) You might also get some mileage out of the "nonuser" macro discussed in "man 5 utmp".
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:42 CDT