Kill pts?

[Dwyane Everts_1]

All,

I have searched the entire forum and internet looking for a solution to a serious problem we have.

Situation:
A user at a remote location starts 3 telnet sessions, and that user is only authorized to have 3 sessions. The frame relay circuit dies for whatever reason, then comes back online. When the user tries to log back into the system (RP8400, HP-UX 11.11), the system still thinks the user has 3 open sessions. Due to the circuit outage, the pts session wasn't closed out properly.

The only way I have found to clear these "dead" pts sessions is to reboot the server. Does anyone have a better solution? Authorizing more telnet sessions is not a valid answer for security and performance issues.

D

[Patrick Wallek]

# ps -ef | grep username

Note the PIDs of the processes

# kill list_of_PIDs

Use 'kill' with NO ARGUMENTS first. That should clean up anything left hanging. Note that this may not perform any application cleanup that is necessary.

[Dwyane Everts_1]

Patrick,

I have tried to kill the the PIDs associated with the pts sessions. The problem is, the system tells me that the PIDs don't exist; even though they are listed next to the pts.

D

[RAC_1]

ps -u"user_name"

Then kill all processes.

[Dwyane Everts_1]

I guess I need to explain myself a bit more....

If I type "who -a | grep ," I will see 3 open sessions with associated pts and PIDs. If I then type "ps -ef | grep ," I will not see the user running any processes on the system.

I thought maybe this was a corrupted "utmp" issue, but even by clearing the "utmp" the issue remains.

D

[Geoff Wild]

What about adding a auto logout for idle time?

Add (15 minutes):

TMOUT=900

to user's .profile - or for all users, add to /etc/profile

If they use csh, then I believe the parameter is:

autologout



Rgds...Geoff

[Dwyane Everts_1]

I will test "TMOUT." Under the circumstances, I'm not sure if that will work since the system in one respect thinks the user is logged out, but in another respect thinks the user is still logged in.

D

[Tim Sanko]

While I took the information that you have here , I went to the executive meditation facility (center stall) and thought you might be able to do this in a more elegant way by closing the sockets opened on the HP box.

It would take the port (easy enought to find and the socket number). Then do a reopen and a close and it might just clean up your problem...


Tim

[Ron Kinner]

Does a TCP/IP connection exist for these orphans? (Do you see the connection still in
netstat -an | grep 23
?)

Does
who -T
show anything funny about the status of the process?

Don't know if it will work on HPUX but:

"cwtmp" ftp://ftp.armory.com/pub/scobins/cwtmp is a freely
available utility that clears stale logins.

Just tried the link and it works. Haven't tried the program. Think it needs to be compiled.

cwtmp.tar.gz 16KB Clean up utmp & wtmp files (discard entries; fix corruption). 2003-Jan-15

Ron

[Patrick Wallek]

You might also want to take a look at some of the ndd parameters. Specifically I think the tcp_keepalive_timer may apply. The default setting for this is 2 hours I think. You might try setting it down to 15 minutes or so.

Do a 'man ndd' for more info.

[Dwyane Everts_1]

All,

I'm going to do my best to relpy to each of you...

Geoff W. - I tried the "TMOUT," that doesn't fix the problem :(

Tim S. - Firstly, thanks for the mental picture, now I need help from a shrink :) Secondly, the ports/sockets for these sessions no longer exist. So, I can't kill them :(

Ron K. - As mentioned to Tim S., the tcp/port/socket was terminated. "who -T" shows the session as terminated also. (I'll have to look into "cwtmp.")

Patrick W. - The tcp_keepalive_timer might work. I assume this variable is set in the /etc/rc.config.d/nddconf file? Although, if "TMOUT" doesn't work, why might this?

All - it appears the tcp session is definitely closed out, but the OS from a "who" stand point is still logged in. Does anyone have any further suggestions?

D

[Mark Grant]

Yes, change the way you determine how many times a user is logged on.

Instead of checking the output of "who" try doing something with "ps" or even incrementing a number you store to a file when you log in and decrementing it when a user logs out. That way, at least you get just change the number to 0 if a user can't log in again.

[Dwyane Everts_1]

Mark,

I have been thinking about (and testing) a new way of determining how many login seesions a user actually has. This will certainly fix the immediate problem, but not the root cause. Thanks for the input.

D

[Dwyane Everts_1]

All,

Mark brought up a very good point. Here is the entry in each .profile that determines the number of times a user is logged in:

UNUM="$(who|/usr/bin/grep $LOGNAME|wc -l)"
if [ "$UNUM" -gt 4 ]
then
echo "\n You are logged in more than" $UNUM "times\n "
echo "\n You can not login more than 4 times\n "

sleep 5
exit
else
exec
fi

As you can see, I don't allow users to log in to a command prompt :) Instead, an application is immediately started. If anyone can think of a better way....?

D

[Mark Grant]

Well, if you are able to use "who"

[ `who | grep $LOGNAME | wc -l` -gt 3 ] && echo "Logged in too many times" && exit

Will do it, but trying the increment/decrement file approach. In .profile

count=0 # Stop test complaining first time we use this

count=`cat .loginfile 2>/dev/null`
[ $count -gt 3 ] && echo "Too keen!" && exit
count=`expr $count + 1`
echo $count > .loginfile

# blah

# Run your application here
myapplication

count=`cat .loginfile`
count=`expr $count - 1`
echo $count > .loginfile
exit


Looks a bit horrid doesn't it.

Or perhaps

[ `ps -ef | grep $LOGNAME | grep "\-sh" | grep -v grep` -gt 3 ] && echo "Nope sorry" && exit

Will do it for you as "-sh" is login shells

[Dwyane Everts_1]

Mark,

I was actually in the process of testing your second option. And I have a new "if" statement that will work. Thanks again!

Does anyone have any more ideas on how to solve the root issue?

D

[Floyd Curtis]

I think Patrick has the right idea with reducing tcp_keepalive_interval.

TMOUT will just affect shell sessions that are idle for long periods of time.

tcp_keepalive_interval controls the interval between when TCP connections are verified. Reducing it to a few minutes will allow the disconnect to be discovered sooner and to release the port at that time to allow its reuse.

good luck
fwc

[Dwyane Everts_1]

Floyd,

I have looked into changing this parameter; but I'm being this issue is related to the "wtmp" file getting corrupted by the "unclean" disconnect. Any ideas how to uncorrupt the "wtmp" file without a reboot?

D

[RAC_1]

fwtmp can take care of corrupt wtmp file.
But I think, you need some code/program that will take care of ressting login count when frame relay dies, and when user comes back after frame relay comes up. So TMOUT and reducing TCP_Keepalive_interval should take care of your problem.

Anil

[RAC_1]

What is the period between frame relay dies and when it comes back again?

What I am thinking is restrict user logins to 3 as you want, then if user comes for the forth time, I will check what all process are owned by pervious three logins sessions. Kill them and allow 4th login. Here I assume that the user comes back for the fourth time because of frame relay problem. Also is there any way to monitoe the frame relay from hp-ux box? IF yes we can do something here.

Anil

[Dwyane Everts_1]

Anil (RAC) and all,

Here is what I have done to "hopefully" correct this issue.

1. The .profile script to detect the number of logins has been modified to use "ps" versus "who."

2. I modified the "tcp_keepalive_interval" in /etc/rc.config.d/nddconf to 960000 (16 minutes).

Anil,
The frame-relay outage time varies (anything from a circuit bounce to an actual outage).

As for the second option, the users here are greedy. They feel they need 12 sessions each to do their job. Multiply that by 1200 users, and you can see the available resources disappear in about 5 minutes. So, I stop them from opening more than 3.

And for monitoring frame-relay from the RP8400, we use NNM 6.2 for this; however, I also have OVOW 7.1 that could play a role if you know of a way to configure a rule for this :) .

I really appreciate everyone's help with this issue! I'm hoping the steps I have taken so far correct the problem, but if there are any other ideas, PLEASE don't hesitate to offer them.

D

[RAC_1]

1. The .profile script to detect the number of logins has been modified to use "ps" versus "who."
>>>

Rather use UNIX95= ps -C"command_you_wantto_grep" or loginshellofuser"
Just doing ps and greping a user will also give a lot of other junk.

And for monitoring frame-relay from the RP8400, we use NNM 6.2 for this; however, I also have OVOW 7.1 that could play a role if you know of a way to configure a rule for this :) .
>>>

Iam not very good at OVOW and NNM, but if you can get a script which notices frame relay problem, then we can kill all previous sessions so that your count of three login is taken care of and if user comes again after frame relay comes back, the count is one.

Anil

[Dwyane Everts_1]

Anil (RAC),

Here is the new script:

UNUM="$(ps -ef | grep $LOGNAME | grep -e '-sh' | grep -v grep | wc -l)"
if [ "$UNUM" -gt 4 ]
then
echo "\n You are logged in more than" $UNUM "times\n "
echo "\n You can not login more than 4 times\n "

sleep 5
exit
else
exec
fi

Hope that clarifies things for you :) .

D

[RAC_1]

D,

You are greping for '-sh'. That what I wanted to tell.

Anil

[Geoff Wild]

Have you tried /etc/default/security?

man security

NUMBER_OF_LOGINS_ALLOWED=N

N number of logins are allowed per user.

Rgds...Geoff