Disconnect user session automatically

[EWONG]

Since many users may not logout their seesion after work, so any way/tool to disconnect the user logon session automatically ?

Thanks a lot.

[Hein van den Heuvel]

There are several 'solutions' in this space, in freeware as well as commercial.
Hitman is possibly the best known of those.

There is even a OpenVMS FAQ entry for it:

http://vmsone.com/~ovmsfreeware/ovmsfwv6/disk2/vmsfaq/vmsfaq_007.html

Google for: +openvms +freeware +"idle process"

I personally don't like any of them, as I believe they cause excessive overhead, end user annoyance and only a false sense of safety.

Specifically, if I have a telnet/puTTY session on a 'locked' PC, then there is no way VMS based sofware can see whether this is safe or not. So they kill it, and then I have to transmit my password over the line again, create a new process, re-execute my environment setup, loose my recall buffers.
Thanks for nothing!

Still, I suppose you gotta do what you gotta do!

Cheers,
Hein.

[Allan Bowman]

Welcome to the forums!

How are the users connecting? Are they using Telnet, or DECserver connections?
Depending on the connection type, there are a number of ways to force them off.
Also, do you want to check if they are actually doing anything, or just dump them at a certain time?

Allan in Atlanta

[EWONG]

Hein and Allan, thanks for the prompt response.

Actually, we use the emulation software Reflection-X (thru REXEC) and Excursion (thru TELNET) to connect to Alpha system. If there has any checking before we kill the session, that would be definitely a benefit.

Thanks in advance.

Edmond

[John Abbott_2 · Accepted solution]

As an example, here's a routine we use, but then we have an SLA to support it. Use at your own risk, etc.

PS.I've slightly modified it to take out some site specific stuff. It's a bit more friendly than a just kill everyone routine. Doesn't do any checking to see if the user/pid is actually doing anything.

John.

[Karl Rohwedder]

Edmond,

here we use the WATCHER package from H.Goatley.
It is very flexible. You find it here:

http://www.madgoat.com/watcher.html


regards Kalle

[Ian Miller.]

I use WATCHER which is highly configurable. It has saved money as you don't need to buy a higher number of user licences.

It does depend on your environment.

[John Gillings]

"Idle process killers" (IPKs) are bad!

They give a false sense of security and if not very carefully written, in extreme cases can cause some very nasty things to happen (for example, if you're running an IPK, never let your process count exceed BALSETCNT). They also encourage users to come up with mechanisms that defeat the IPK. Very easy to do, and generally wasteful of resources.

Rather than kill the process suspected of being idle, a better option would be to enable virtual terminals and disconnect the TELNET connection. That way the user can log back in to the session without losing any work. I'm not sure if any of the off-the-shelf solutions are capable of doing this.

That's all if you're attempting to figure out if a particular process idle from "outside" (even in theory, practically impossible). On the other hand, if you're writing an application with some kind of command loop, it's very easy to impose a timeout on command input and exit/logoff cleanly.

[Thomas Ritter]

John, IPK maybe bad, but on all or our production hosts its mandatory. Even at the business end it is supported. For example, one group of users has an idle limit set at 15 minutes. We know our applications really well can precisely determine their "idleness". We use KBLOCK with a modified routine that starts with a $FORCEX followed by $DELPRC. Further the application has an exit handler which responds to $forcex. Works most of the time. The success of IPK deployment depends a lot the application and OS interaction. In the early delays some application components held "lock" during "operator wait time" and at termination started a change of RDB rollbacks. :( Those troublesome application components have since been addressed. When you introduce an IPK make sure you understand what can happend if any type of application or recovery work may follow the termiantion request.

I am not endorsing KBLOCK.

[John Gillings]

Thomas,

>We use KBLOCK with a modified routine
>that starts with a $FORCEX followed by
>$DELPRC. Further the application has an
>exit handler which responds to $forcex.
>Works most of the time.

If the application has an exit handler especially written to handle an IPK, why not just implement the idle timeout in the application itself and avoid all the potential problems? Much easier to issue a command READ with a timeout and take the timeout condition to be equivalent to an EXIT command. Very simple, very effective and much safer than shooting processes.

[Thomas Ritter]

John, sure, but our selection criteria is very involved. We have different rules for different groups. From a commercial perspective it is easier and cheaper to have the IPK external.

[John Abbott_2]

> It does depend on your environment.

I think Ian hit it on the head here.

Virtual terminals work great for developers and admin, great for continuing a session from another site.

For users, it just doesn't work for us, their expectations are different;
-some simply close down the telnet session and don't want to ever reconnect
-some users simply just don't understand it, whilst those that do want more... i.e. why doesn't the screen appeare as I left it (CTRL-w is the reply) why when I continue to enter the details in the app does the update fail ('cos you've held the record too long (connected 3 days later)) why doesn't the screen display correctly (80 vs. 132 width).
-we end up with more interactive sessions
-more helpdesk calls
-when apps are updated the installed image goes delete pending, these never free up without intervention - gets a bit large as the months go by.
-they expect a disconnected session to survive a maintenance outage

I also don't like idle killers (operating throughout the day). I'm more interested in the jobs that are stuck in a tight loop!

There's also the risk that users left logged in cause FAC

J.

[Karl Rohwedder]

...
I also don't like idle killers (operating throughout the day). I'm more interested in the jobs that are stuck in a tight loop!
...

We use the DYNPRI utility (from M. Madison) to dynamically adjust process priorities.

regards Kalle

[Ian Miller.]

Some of the reasons why using idle process killers work or dont work in various environments have been outlined. Like many security problems its really a people problem. You educate your users to logout but technology can also be needed to backup the education as people are fallable.

[John Abbott_2]

RE: DYNPRI

I ended up coding my own, but I'll still take a look at this, so thanks !

[Phillip Thayer]

I agree with what Ian and others are saying about depending on the environment your system is running in. It is also important to have users who understand what may happen if you have an IPK running. I had one place I worked at where the users were so uneducated about what was happening I would get calls from users complaining that the system had "crashed" so the restared VMS and everything was o.k. The first time someone called me and said that I almost had a heart attack. Then when I went down to their desk to find out what they did they proceeded to "shutdown and reboot" the VMS system by logging off, turning off the VT monitor, turning on the VT monitor and logging back in. Then they said, "See I shutdown and rebooted the VMS system."

So. if you have users who really don't know what is happening you can create a storm of users calling with things like that.

Phil

[Jan van den Ende]

Edmond, all others:

Much as I do not like IPK, and I am also sensitive to John's arguments, we also have reasons (and I agree with their validity) to do something in this area. Rather crude, but quite satisfying to us.
- As no user is ex[ected to work more than 8 hours a day, we kill any interactive process after 10 hours past logintime. Any user still logged in then is considered to have forgotten to log out.
Since nearly everyone connects via Citrix, just setting aside a session and forgetting it is not uncommon.
(Our two major database applications have their own inactivity handling, and those will be disconnected long before anyhow).
Some of the other apps do not like to have active users during backup, and/or night-time batch processing, so users of these apps are kicked out at that time anyhow.

Of course, occasionally some users DO need to run lengthy processes, sometimes interactively. Those tend to be eigther System Managers or Application Managers, and those occasions are to be planned beforehand anyhow. So, at request, such user is added to an exception list, but only for 24 or 72 hours (weekend). Any longer need, and it will have to be refreshed in time.

-- Maybe not perfect, but it works for us, and the advantages way outweigh the disadvantages.

hth

Proost.

Have one on me.

jpe

[EWONG]

Dear all,

I am very much appreciated your suggestion and valuable information.

Thanks a lot.