Conference noted::hackers_v1

588.0. "VMS and LAT idle process killers" by NANUCK::SSMITH (Minnesota Vikings' couching staff) Thu Oct 22 1987 14:39

    This was moved from the BUSY conference. 
    
               <<< METOO::DISK$STC:[NOTES$LIBRARY]BUSY.NOTE;3 >>>
                           -<  BUSY utility Notes  >-
================================================================================
Note 43.0                     busy being logged out                    3 replies
CIMAMT::WESTERVELT                                   12 lines  20-OCT-1987 12:45
--------------------------------------------------------------------------------

I am new to busy, and have installed it privately.
Sometimes (not always) when I leave busy in charge,
someone (maybe lat, maybe vms) disconnects my session.
I think this logs me off altogether.  Can this be
prevented/controlled by me?  Maybe it has to do with
a shortage of lines (or maybe not).  Does vms (lat?)
look to see that I am running busy, or does it simply
check for idle processes?

I have scanned this notes file, don't see this mentioned
previously...

================================================================================
Note 43.1                     busy being logged out                       1 of 3
NANUCK::SSMITH "Minnesota Vikings' couching staff"   12 lines  20-OCT-1987 19:15
                -< Idle Process Killer not *inherent* to VMS. >-
--------------------------------------------------------------------------------

    Don't know about LAT.  VMS doesn't do anything.  If your process is
    being terminated at the VMS level, then there is some program setup by
    your system manager on VMS which is checking some criteria for
    termination.  Most programs of this form just look for idle processes.
    Invoking BUSY with the /INTERVAL=1 minute qualifier *may* be sufficient
    to fool the program into thinking your terminal is active.
    
    There have been extensive discussions about such programs in the
    HACKERS and VMS SUPPORT conferences.  If you want further information
    about them, I suggest you look in those places.
    
    -- Shel Smith
================================================================================
Note 43.2                     busy being logged out                       2 of 3
CIMAMT::WESTERVELT                                   12 lines  22-OCT-1987 10:41
                                 -< re .1,.2 >-
--------------------------------------------------------------------------------

The actual message I get is 
	
	local -011- Session 1 disconnected from cimlab

where cimlab is my machine which I connected to using lat.
So I *suspect* vms is not the culprit.

busy is a nice tool, but it's not too useful if I keep
getting zapped...



================================================================================
Note 43.3*                    busy being logged out                       3 of 3
NANUCK::SSMITH "Minnesota Vikings' couching staff"   23 lines  22-OCT-1987 13:34
                   -< Still don't know where the problem is >-
--------------------------------------------------------------------------------

.    	local -011- Session 1 disconnected from cimlab

    All that tells you is *something* caused your link from the terminal
    server to CIMLAB to be broken.
    
    It could be the terminal server timeing out, CIMLAB going down, or even
    an overly busy ETHERnet.

    Depending on your terminal server, try a command like SHOW TERM or SHOW
    PORT and see if "inactivity" shows up anywhere.
    
    On your system, do a $ SHOW SYSTEM and look at the process names.  Some
    known programs are: WATCHDOG, SPIRIT, CHIPMUNK, and SECPACK_IPM.

    If the problem is happening during the day, then talk to your system
    manager about altering in your case.  If you don't like the answer,
    talk to your Cost Center Manager.  Depending on what you are doing,
    useful time and effort may be being lost by your getting stopped.
    
    -- Shel Smith

    P.S.  This would be better if discussed in the UFP::HACKERS notes file.
    <select> and all that.

My busy seems to get zapped past 5 p.m.  Sometimes it send me
the following ominous message:

%autologo-w-warn westervelt might be logged out for security 22-oct-...

$show system reveals none of watchdog, spirit, chipmunk or secpack_ipm.
It *does* show "autologout"... hhmmmmm....

Tech. support is looking into this for me.  

P.S.  Is it bad for a vt240 screen to have a busy message written on
it all night or weekend?  With the time being updated every so often,
it's not going to have a chance to blink off like it usually does when
it's feeling ignored.

	why in the world is it necessary to keep a process alive
	that you're not going to be using for an entire weekend
	let alone overnight?

	i know a lot of work has been done to make BUSY a secure
	program, but it's not any more secure than logging out,
	in fact it is less secure.

	with BUSY someone can sit there all weekend trying to guess
	your password whereas if they tried to login that many times
	some security alarms would probably be set off.

	P.S. it also wouldn't hurt to turn your terminals off over
	     the weekend or maybe even overnight even though it's
	     not really "your" money being wasted.

You are quite correct that running busy all night or weekend is a needless 
waste of resources.  The question was a technical one relating to
the engineering of terminal screens. 

Busy is especially useful for relatively short
absences (say, up to an hour, but more often about 10-15 minutes' worth).
On my system at least, logging on takes a lot more time than just
exiting busy, especially if you mainly want to check for messages.

Getting zapped afterhours is a problem if you are working on a 
night or weekend.  If it's Thursday night or Saturday morning, autologoff
isn't necessarily going to care that you are really there working and
not mindlessly squandering company money.  *zap*

Running BUSY all night or weekend is not at all a "needless waste of resources,"
if you've spent a whole day getting your process into the state it's in when
you run BUSY.

--PSW

Turns out "autologout" keeps a file of things it likes to ignore when
considering cpu usage.  busy is sometimes one such unfortunate.