Kill pts?

[Dwyane Everts_1]

Geoff,

Great Idea!! In fact, I tried that once. Only once! And the "Management" decided they were above the law, and needed at least 6 each. I have had to create 2 "user" home directories for just this reason. The standard /home has all the regular users with the .profile described in this posting, and a /user directory for those deemed "exceptional." I appreciate the idea though!!

D

[Ron Kinner]

If netstat -an does not show the connection as being still there then there is no point in fooling with the tcp_keepalive_timer.

Ron

[Dwyane Everts_1]

Ron,

That has been my problem all along. "netstat -an" doesn't show a session open, "ps" doesn't show any running processes, but "who" shows the person as still logged in.

I believe I have corrected the immediate problem of logging in; however, the root cause of the issue is still not resolved, and I will still have to reboot the server more periodically than I like to clear the "wtmp". Unless you have a better solution :)

D

[Ron Kinner]

I'm not sure the link for cwtmp was correct.

http://www.armory.com/~ftp/ and look at the bottom of the page for cwtmp.tar.gz I just downloaded that one and was able to read it with winzip.

Also another version at:

http://www.geocities.com/SiliconValley/Network/2894/

Also found this:

kill -0 `who -u | awk '{print $7}'`

The -0 is minus zero and not minus oh.

Supposedly this creates a list of all stale logins. I don't have an HP-UX left to play with to check it. We turned the last one off last month. I just tried
who -u | awk '{print $7}'
on an old Linux box and it just gave me the ip address I logged in from but looking at my Linux in a Nutshell it looks like it should work on a newer system to give you the pid then the kill -0 will test it. Not sure that the resulting output is much use but I suppose if you ran the who -u and grepped for your user before running the awk you would get a count of the dead logins for that user.

Ron

[Dwyane Everts_1]

Ron,

The "who" command is part of the problem, and doesn't give an accurate reading. To summarize everything we have discovered so far...

According to "netstat" (the networking side), the session is terminated.

According to "ps" (the process side), there are no running processes for the user or users in question.

According to "who" (the logging/accoutability side), the session is still alive.

Clearing the "utmp" file, doesn't correct the issue.

I believe the "wtmp" file is somehow becoming corrupt. "cwtmp" may fix the problem, but I'm not a programmer and don't know how to compile these type of apps.

D

[Ron Kinner]

Post a question in

http://forums1.itrc.hp.com/service/forums/categoryhome.do?categoryId=150

and give them the link to cwtmp. Ask them where you can get a compiled version for hpux 11.11 or how to compile it on your box. Odds are someone will compile it for you and send it to you or post a zip copy for you.

The software in the second link has a note in the remarks header which tells you how to compile it. It wouldn't hurt to try and see if it works.

Ron

[Floyd Curtis]

Dwyane,
Regarding the who command incorrectly reporting of terminated telnets, I know there have been patches for 10.20/11 for this type issue. You may be way beyond this, but if not then doing a search for 11i patches for telnet and close or corrupt would probably give you a current list worth looking at. Certainly any telnet or streams cumulative patches would be good bets.

Also, the wtmp/utmp files should not be corrupted by dropping a "telnet" session, no matter how it is done. If a different application has the connection, then "it" has the responsiblity to close up things nicely so all bets are off there. You should not have to use a tool (fwtmp or 3rd party to correct this - they should really only be needed in extra ordinary circumstances.) If you have access to the knowledgebase, there is a doc that describes your scenario that was resolved with the tcp keep alive timer being reduced to quickly identify and release the ports.

fwiw,
fwc

[Dwyane Everts_1]

All,

I have taken each suggestion made here and implemented it. The root cause of the problem still exists; however, the new script doesn't lock the user out of the system. I guess a workaround such as this, is the best I can hope for. I appreciate all the help from each of you!!!

D