UNIX for Dummies Questions & Answers

If ksh is the login shell, try to set TMOUT variable in user's .profile and see if it helps you.

I think this is either going the wrong way, or maybe I'm not understanding what's being said.

The "idle process" you are talking about is not telnet or the shell, but rather an instance of the application that's being run through said telnet session, right?

In other words:
User telnets to box, starts application.
User closes terminal without properly exiting application.
User's session terminates, but application process keeps on running.

And what you want to find out is how to differenciate those application processes that are still running that where not properly shut down when the user terminated his telnet session, so you can safely kill them. Right?

If that's the case, i.e., the application process doesn't die when the telnet session is killed, then loking at user idleness is not going to help, since there actually won't be a user session associated with said application process.

I'd say first that I agree with what grial said - the app should catch ithe session being terminated -, anyway, without knowing specifics - and you know the devil is in the details -, I'd think that a simple parse of ps -ef would do the trick. Rather than looking for idle sessions, you can match PID's with a simple script. Quick example:

user1 logs in, so it creates some processes. One of the is the user's shell. When that user starts some application, that application process should show the user's shell as the application process' parent ID. I would think a simple match of said IDs in a cron job would do the trick; something like:

Code:

process=$(ps -ef | grep <my_application_process> | awk '{print $2}') 
parent=$(ps -ef | grep <my_application_process> | awk '{print $3}') 
count=$(ps -ef | grep ${parent} | wc -l)  ## this should catch at least 2 processes: 
                                          ## the PPID of application and the PID of
                                          ## user's shell
if (( ${count} < 2 )); then  ## if it only catches one, it'd mean user is no longer logged in
kill -9 ${process}
fi

Now, the above example is very simplified. You'd probably need to play around with arrays and other stuff, but hopefully it gives you the idea.

And, like I said before, if I misunderstood what's being asked, then, nevermind

That's what I think It is.

Thanks. Of course, I would prefer the "programming solution" but, this would be a possible one. The easy one for me.

But you forgot "grep -v grep"

Anyway. Doing a little search on google (I'm not a C programmer), I came across with this:

http://www.metalshell.com/view/source/92/

It's a peace of code in which signals are catched and treated. Basicaly, it uses the "signal" system call to catch a (HUP) signal. Perhaps it helps you...

Like I said, the devil is in the details

yeah! That's right! heheheheh

Hi all,

Sorry for late reply and thanks for your advise.

This is exactly the problem I am facing now. But it is not necessary user logout abnormally, sometime could be due to network connection failure and caused the application ended. I noticed that the shell and the application PID are both still active. Below are some typical example that extract from server.

root# who |grep 10.1.1.144
jbmkt1 pts/82 Jun 22 11:11 (10.1.1.144)
jbmkt1 pts/83 Jun 22 09:50 (10.1.1.144)
jbmkt1 pts/226 Jun 22 10:34 (10.1.1.144)
jbmkt1 pts/249 Jun 22 10:53 (10.1.1.144)

root@ # ps -ef |grep db |grep jbmkt1
jbmkt1 20432 20331 2 10:53:34 pts/249 0:52 /u/recital/db.exe -x menu
jbmkt1 22156 22089 0 11:11:46 pts/82 0:00 /u/recital/db.exe -x menu
jbmkt1 17993 17948 2 10:34:44 pts/226 0:54 /u/recital/db.exe -x menu
jbmkt1 10055 9955 2 09:50:55 pts/83 2:27 /u/recital/db.exe -x menu

root # ps -u jbmkt1
9955 pts/83 0:00 sh
20432 pts/249 1:00 db.exe
22156 pts/82 0:00 db.exe
20331 pts/249 0:00 sh
22089 pts/82 0:00 sh
17948 pts/226 0:00 sh
17993 pts/226 1:03 db.exe
10055 pts/83 2:37 db.exe


from the above you can see those logins earlier have ended abnormally due to network problem, but the session seems still active for both shell and application, I will have to manually verify and kill those inactive session, if not the load will getting higher and slower.

This is what I meant, but if you based on the count, it is also appropriate, right ?

Please advise further.

Have a nice day.

Thanks & Rgds
T.W.Low