Kill Users process

[Karthick K S]

I want to kill users(not root) process except active sessions how could i write script

PIDS=ps -af | awk '{print $2}'

i received the PIDS but how should i check whether active sessions. and also it should not be root process.

[RAC_1]

What exactly are you trying to do?? What do you mean by active sessions?? telnet sessions?? ssh sessions??

The process states changes every millisecond due to time sharing scheduling and so the process which is in running state now may be in wait, sleep, ready to run state after few miliiseconds.

If you want to log out inactive telnet sessions/ssh sessions, you can put TMOUT varibale. export TMOUT=100, will disconnect the session after 100 seconds.

If you want to kill user process, then you can do as follows.

ps -u"user_name|grep -iv [P]ID|awk '{print $1}'|xargs kill -15

Anil

[Arunvijai_4]

Are you trying to kill processes started by particular users and still running eventhough that particular user logged off ?

-Arun

[Karthick K S]

I want to kill telnet session as well as others process(like dbms).

And daily evening i want to kill inactive sessions i.e only one session should be active(if some users opened 3 session that
time i want to kill 2 sessions except current runing one).

[Jeff Schussele]

Hi,

I agree with RAC.
This is exactly what the TMOUT variable is designed for - to kill idle sessions.
MUCH safer than just killing processes.

My $0.02,
Jeff

[Karthick K S]

I understand TMOUT is better than kill the process this is only for idle sessions.

But i want to kill if users opened 2 or 3 sessions or process and and also logoff users process except current runing session.

[RAC_1]

As I said, process state changes very fast. So by the time, you check it and it was running state, it could be be something else, by the time you finished checking it.

You can control no. of logins. man 4 security. Prepare /etc/default/security file and put NUMBER_OF_LOGINS_ALLOWED=2

This will allow 2 simulataneous logins only.

[Jeff Schussele]

Well...the TMOUT will kill the idle shells and because they are the parent PIDs of every thing spawned underneath them, all their children die as well.
It's just MUCH to dangerous to grep stuff out of ps command & kill them. You're likely to kill something that you shouldn't & crash the system.
But I guess if you're a gambling man.....

Rgds,
Jeff

[Arunvijai_4]

Just a note, check this thread before setting /etc/default/security and NUMBER_OF_LOGINS_ALLOWED

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=305690

-Arun

[Karthick K S]

This is only for kill users process at end of the day only i am not restrict login session.

[Karthick K S]

Pls anyone help me out this

[RAC_1]

Karthick,

You are not reading the replies carefully.
As such there is no magic wand to kill processes based on their state. (because they change very fast. and very fast means almost not catchable and noticable)

If you open a telnet session and just start vi and do nothing further, it is still a active session for system. But in fact it is inactive session because nothing is happening in vi. Said that, you need to way to decide (from apps/program side) to say that it is inactive.

[Tom Schroll]

This type of request seems to come up over and over -- unfortunately, I only know of one public tool that does a pretty good job of actively controlling user sessions.

http://www.darkwing.com/idled/

I haven't used it much myself, and it may need some tweaking to compile on HP-UX. But give it a shot.

I wish I could help you with your script, but there really isn't any safe and easy way to script everthing that you want to do...at least not one that I would feel comfortable with. :-) If you still want suggestions on how to parse output from ps, that's fine, we can help. Otherwise, I suggest a long look at idled (or perhaps write a similar program like it).

-- Tom

[Howard Marshall]

I don't really have any more of an answer for you than anyone else has but perhaps I can explain why they have given you the answers they have.

You use the term "inactive session". You seem to be defining an inactive session as any processes or logins that are running but that no human is currently using. The system doesn't and can't know if there is a person sitting there or not.

Inactive in this case is your term, not the systems, so, there are no switches in the ps command that can identify if a "session" is "inactive" or not

You will have to decide what the criteria are that makes a session active or inactive. Once you decide what the criteria are you can find a way to identify them perhaps by tty or something and go from there.

It may also help if you gave us a little more detail about what a "session" is. Do the users login with a terminal, a terminal session from a pc, to they access the system through some x terminal program or are processes spawned for them from a client server type application that doesn't require them to login to the server through the usual login process?

Its not that we don't want to help you,

Based solely on the information you have given you may have to write a script that goes through each user for processes and use the start time of the process and eliminate all but the most recent. The problem with that is, a user may create a session, move to another location, create another session, go somewhere else and create a third, then come back to the second. The system has no way of knowing that, itâ s the chance you have to take unless you can use tmout to kick them off based on idle time

I know that doesn't help much but⠦⠦

Howard

[Jeff Schussele]

Well said Howard.
But you know sometimes some people just want a fish & could care less when you're trying to taech them the finer points of casting....

Jeff

[Karthick K S]

Thanks to all for such good reply.
I got it clearly.

[Howard Marshall]

Just so everyone knows,

The characters after that last sentence were not typed as displayed. What I typed was a series of periods but I guess because I write stuff in word for the spelling correction it translated it wrong, in this case it seems a little vulgar and I apologize for that.

H