Automatic logout after #--minutes idle OpenVMS

[geir_2]

Hi,

In Cisco you have a command that logout out the user if the connection is unused. You can decide how long time it should take before the user logged out of the system.

It's also possible to configrue the console and telnet port

line con 0 {vty 0 4)
exec-timeout #-minutter #-seconds

So my questions is:
Is it possible to do the same on OpenVMS??

[David B Sneddon]

Geir,

There is a freeware product called WATCHER which
can be configured to do what you are after.

It is on the FREEWARE4 CD and also at
http://vms.process.com/scripts/fileserv/fileserv.com?WATCHER

I believe there are others but I have used WATCHER
for a number of years now with no problems.

It has a lot of configuration options and flexibility.

Regards
Dave

[geir_2]

hi,

thanks for the answer. But if possible I would prefer to use a standard command in VMS if possible.

The VMS system is located in a secure network, and it could be scary to use unknown programs.

regards geir

PS:
I'm sure that the program is OK, but I don't
dare to use it. Sorry for me.

[David B Sneddon]

Geir,

There exists no funcionality within native VMS
to perform this task. You either write your own
(which I have done on one occassion) or use what
someone else has written.

Dave.

[David B Sneddon]

The other thing to bear in mind is that lack of
activity on a telnet connection is NOT an indication
of an idle process. There are many things that can
be used to determine whether a process is idle or
not.

Dave.

[geir_2]

hi,

Thanks for the answers. I thought that VMS didn't have any solutions on the problem.

But of course, it's possible to write
com-files. I hoped I could avoid it.

Thanks again David

regards Geir

PS:
Do you know where I could find different com-files??

[David B Sneddon]

If you can decide how you want to define an idle
process, it shouldn't be too hard to use f$getjpi
to extract the information and make the necessary
decisions. If you are going to write your own,
it may be worthwhile looking at the source for
WATCHER to see how it does it then try to put that
into your own DCL. But if you go down that path
it would be better to use WATCHER -- the source
code is included if that is what the security issue
is about. You can examine the code and decide for
yourself whether it is "safe".

Good luck.
Dave.

[Mobeen_1]

We use a product called HITMAN that is free to do this. I know that its also possible to do this at the TCPIP level (there was a parameter we use to setup in TCPware)

regards
Mobeen

[Ian Miller.]

"I know that its also possible to do this at the TCPIP level (there was a parameter we use to setup in TCPware)"

Is this a reference to the keepalive processing in tcp which can be enabled for telnet so if a remote system goes away (user turns pc off without logging out) then the telnet session eventually will be ended.

[Willem Grooters]

A word of warning if you use applications that access RMS-files.

If an application opens a lot of files, and writes (especially updates) a number of them, be sure to define precisely what you determine as "idle" before a process is killed.
We have experienced, in our application, that is some cases, file updates are lost if a process is simply "killed" without flushing it's buffers to disk. Just interrupting a line of activity, because "nothing seems to happen", does not mean that all IO has been done or finshed. A blunt stopping of a proces can therefore introduce (potentially severe) inconsistence in your files, even cause corruption of files or disks.

[Bojan Nemec]

I agree with Willem. Its much better to use SYS$FORCEX (or the new STOP /IMAGE from DCL). A long time ago I write two programs. One was able to get process informations and mark sleeping processes. Another, interactive program, was able to display the processes and give to the operator the choice which process to stop (forcex and stop).

Bojan

[Jan van den Ende]

I would like to add two more 'points of interest'

-- An interactive process might be seemingly sleeping, while it has (a) supproces(ses) doing the work. Not so very uncommon...

-- A process might be a front-end, that is having a (database-?) server process working for it, and just waiting for an answer.
For some queries, that can take quite some time. You want to be sure NOT to kill your front-end in the meantime...

Proost.

Have one on me.

Jan

[John Gillings]

geir,

As others have said, there is no "standard" OpenVMS command to timeout users after some period of inactivity. One reason for this is it is extremely difficult to determine "inactivity". For example, ss some have mentioned a process may appear inactive, but have active subprocesses.

Assuming you have some reliable way to identify inactive processes, there is also the issue of deciding HOW to safely kill a process. Again, you've already seen some discussion about his - demonstrating that there is no hard and fast answer.

The best place to implement an inactivity timeout is in your application. Give your command prompt a timeout period. If it trips, then exit the application and logout the process. This isn't a general solution for all interactive users, but it's easy to implement and can be as safe as you want to code it.

There are many potential reasons why you should avoid attempts at general solutions to this issue. The WATCHER and HITMAN type "solutions" have been known to cause serious problems in various circumstances.

Something that might help that IS part of OpenVMS are access time limits on usernames. See the UAF command MODIFY/ACCESS.

[Russell Jones · Accepted solution]

I have written a DCL program that will monitor IDLE processes and logout the process automatically depending on the time set the process is IDLE...

It might help...Good luck...

Here is the portion of the code:

$ LOOP_MAIN:
$ ON ERROR THEN CONTINUE
$!get currently running processes' PIDs
$
$ CONTEXT = ""
$ LOOP00:
$ PID_NO = f$pid(CONTEXT)
$ if PID_NO .eqs. "" then goto EXIT_LOOP00
$
$!get the information about the returned PID
$
$ TERM_NAM = f$getjpi(PID_NO,"TERMINAL")
$ PROC_MODE = f$getjpi(PID_NO,"MODE")
$ PROC_CNT = f$getjpi(PID_NO,"PRCCNT")
$ USER_NAM = f$element(0," ",f$getjpi(PID_NO,"USERNAME"))
$
$
$!filter out the interactive OPER processes
$ if TERM_NAM .eqs. "" -
.OR. PROC_MODE .nes. "INTERACTIVE" -
.OR. USER_NAM .nes. "OPER" -
.OR. PROC_CNT .gt. 0 then goto LOOP00
$
$!get the IO information about the returned PID
$
$ PROC_NAM = f$getjpi(PID_NO,"PRCNAM")
$ BUFIO_CNT = f$getjpi(PID_NO,"BUFIO")
$ DIRIO_CNT = f$getjpi(PID_NO,"DIRIO")
$ CURR_PROC_NAM = f$fao("!14AS",PROC_NAM)
$ CURR_BUFIO_CNT = f$fao("!8UB",BUFIO_CNT) + 0
$ CURR_DIRIO_CNT = f$fao("!8UB",DIRIO_CNT) + 0
$ TERM_NAM = f$getjpi(PID_NO,"TERMINAL")
$ REC_STAT = 0
$
$!compare the current PIDs IO info with the previous and KILL it if needed.
$ gosub COMP_IO
$
$ if USER_NAM .eqs. "OPER"
$ then
$ if REC_STAT .gt. 2 then goto LOOP00
$ endif
$
$! write the process infos into current processes database
$ NEW_RECORD = f$fao("!8AS!14AS!8UB!8UB!10AS!2UB",-
PID_NO,CURR_PROC_NAM,CURR_BUFIO_CNT,CURR_DIRIO_CNT,-
TERM_NAM,REC_STAT)
$ open/append NEWFILE DISK$PROMSRC:[STATSFILES.SALEMR.ZAPPER]USERCURRX1.DAT
$ write NEWFILE NEW_RECORD
$ close NEWFILE
$
$!get next process PID
$ goto LOOP00
$
$ EXIT_LOOP00:
$!END of LOOP00
$
$! wait for two minutes before going back to loop.
$ wait 00:02:00
$ goto LOOP_MAIN
$
$!END of MAIN LOOP
$
$
$
$!
$!xxxxxxxxxxxxxxxxxxxxxxxxxxx s u b r o u t i n e s xxxxxxxxxxxxxxxxxxxxxxxxxxx
$
$ COMP_IO:
$
$ open/read OLDFILE DISK$PROMSRC:[STATSFILES.SALEMR.ZAPPER]USERPREVX1.DAT
$ LOOP01:
$
$ read/end_of_file=EXIT_LOOP01 OLDFILE OLD_RECORD
$ PREV_PROC_NAM = f$extract(8,14,OLD_RECORD)
$ if CURR_PROC_NAM .nes. PREV_PROC_NAM then goto LOOP01
$
$ PREV_PID = f$extract(0,8,OLD_RECORD)
$ PREV_BUFIO_CNT = f$extract(22,8,OLD_RECORD) + 0
$ PREV_DIRIO_CNT = f$extract(30,8,OLD_RECORD) + 0
$ REC_STAT = f$extract(48,2,old_record) + 0
$
$ if PREV_DIRIO_CNT .eq. CURR_DIRIO_CNT
$ then
$ if PREV_BUFIO_CNT .eq. CURR_BUFIO_CNT
$ then
$ if USER_NAM .eqs. "OPER"
$ then
$ open/append KILLEMFILE DISK$PROMSRC:[STATSFILES.SALEMR.ZAPPER]KILLEM1.COM
$ write KILLEMFILE "$ stop/id=",PREV_PID
$ close KILLEMFILE
$ reply/nonotify/bell/terminal='TERM_NAM' -
"<**** K I L L E D !! 5 minutes of inactivity ... You're logged-off!! ****>"
$ stop/identification='PREV_PID'
$ endif
$ endif
$ endif
$ purge DISK$PROMSRC:[STATSFILES.SALEMR.ZAPPER]*.*
$ rename/log DISK$PROMSRC:[STATSFILES.SALEMR.ZAPPER]*.*;* -
DISK$PROMSRC:[STATSFILES.SALEMR.ZAPPER]*.*;1
$ EXIT_LOOP01:
$ close OLDFILE
$
$ return
$! END OF subroutine COMP_IO

[Jeroen Hartgers_3]

"$ stop/id=",PREV_PID

It is a very brute way to stop a process this way. I do not know what your users are doing on the system. I think you are getting trubble with a lot of users, because you has defined 5 minutes. If an user is getting a drink or looking up some information someware else he/she is loged out.

[John Gillings]

Re: Russell's DCL

A much more insidious problem with this type of approach is our old buddy Heisenberg.

Consider, some of the data you're sampling from the process is done in the context of the process itself using an AST. Thus the process is made computable. If it was outswapped at the time of the probe, that means an inswap.

Now, if the system happens to already have BALSETCNT processes, then any inswap requires an outswap. The net result is your process scan will "chase" the swapped out processes down the process table. With enough processes on the system, all that swapping will extend the time to complete the scan until it exceeds the loop delay interval. Your entire system is now toast! spending all its time swapping processes in and out.

This is NOT just theoretical, we've seen the symptom numerous times, and in all cases I've seen the culprit has been an Idle Process Killer (IPK).

The usual "fix" for this is to check the target processes state first (which won't require an inswap), and ignore any that are outswapped. The irony of this is, if a process is outswapped, it's not likely to have been very active recently, no?

As you discover these types of issues (and there are MANY more!) your IPK gets more and more complex, has more and more loopholes and drifts further from the original intent. Worse, you TEACH your users that they don't need to log off, because the system will do it for them.

It's not an oversight that OpenVMS doesn't have an Idle Process Killer build in...