topic Re: Audit alarm for timeout during login in Operating System - OpenVMS

Audit alarm for timeout during login

Wim Van den Wyngaert — Thu, 31 May 2007 06:21:27 GMT

I would like an audit alarm when a decnet or other login fails due to a timeout.

E.g. on a very very loaded system with name node (load simulated by a dcl loop at prio 8)

$ dir node::
Gives after 55 seconds
ACP file or directory lookup failed
network partner exited

Accounting says :
file not accessed on channel and elapsed time 54 sec at prio 4.

Nothing in audit and I have network login failure enabled.

With the same load, rsh goes well. After about 1m15sec the output comes. Accounting shows ellapsed time all lower then 55 sec.

Wim

Re: Audit alarm for timeout during login

Robert Gezelter — Thu, 31 May 2007 06:38:57 GMT

Wim,

This is a classic problem. There is a fundamental difference between rsh and a FAL listener connect. (The CPU load is only an issue if you are in a uniprocessor system).

rsh does not know who you are at first, so it is running at a higher priority. DECnet FAL connections start a process using the supplied (or proxied or default) access control. Thus, the process is running at a far lower priority (the experiment is to try the same test on an account that has a priority of 8 or 9; it will most likely work).

There is also a DECnet server timeout (it is documented in the manual, but I have to leave for a meeting so I do not have the time at this instant to give the precise citation).

My recommendation on situations of this type (since the days of the VAX-11/780):
- reduce the size of login scripts in the case of network server processes (the command definitions and many other things are simply not needed)
- increase the DECnet server timeout value to a large number

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

Re: Audit alarm for timeout during login

Wim Van den Wyngaert — Thu, 31 May 2007 06:42:35 GMT

As expected, it works when I put prio on 9.
But can't do that in real life.

And why is this not considered a login failure ?

Wim

Re: Audit alarm for timeout during login

Robert Gezelter — Thu, 31 May 2007 11:43:36 GMT

Wim,

It is not a login failure because the login worked (correct username/password and no other violations). The problem is that the server image (e.g., FAL) is likely not starting before the network timeout.

As I noted earlier, check the login for the account AND consider raising the DECnet timeout. The first time I encountered this syndrome was over twenty years ago, at a university during finals week. The machine was simply very busy AND one of the systems managers had greatly enhanced the standard login profile WITHOUT conditionalizing things as to whether they were needed in network or interactive startups. In that case, I recall fixing BOTH:
- conditionalizing many things in the login sequence
- changing the timeout (my recollection is the name NETSERVER$TIMEOUT; check the correct DECnet Management Manual)

- Bob Gezelter, http://www.rlgsc.com

Re: Audit alarm for timeout during login

Dean McGorrill — Thu, 31 May 2007 12:28:35 GMT

I'm trying to remember this part of the code. there is no login failure, so no
audit posted. we posted audits on bad username password for example. I'd say
the process is authenticated, the link brought up then fires the server. the
server times out and we tear the connection
down.