Automatic logout after #--minutes idle OpenVMS

[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...