topic Re: Login with a high priority in Operating System - OpenVMS

Login with a high priority

Wim Van den Wyngaert — Thu, 21 Apr 2005 01:59:00 GMT

Sometimes, I encounter looping processes on a node. When I try to login, it takes minutes to complete. Yesterday I had the problem with DDP of DSM and after login, stop/id didn't result in a stop of the process. I had to reboot.

Is there an (undocumented) feature to allow high priority login (t.i. with a process priority of e.g. 16) ? And I don't mean changing the sysuaf prio.

Wim

Re: Login with a high priority

Volker Halle — Thu, 21 Apr 2005 02:07:16 GMT

Wim,

how about AMDS/Availability manager - no login required to stop looping processes or just lower their priority or suspend them.

And force a crash, so you could analyse the reason for the loop ;-)

Volker.

Re: Login with a high priority

Wim Van den Wyngaert — Thu, 21 Apr 2005 02:17:52 GMT

Volker,

Yes it's a solution but :
1) AMDS could not lower the priority because the processes wasn't listening
2) I like to investigate before I crash the system

No, I would like a high pri login.

Wim

Re: Login with a high priority

David B Sneddon — Thu, 21 Apr 2005 02:44:00 GMT

Wim,

Can you modify your priorty in the UAF (to 16) then drop it
manually once you login? The login process starts out with
a higher priority then drops it to the UAF value later in
the login process.
At least this way you should always be able to login in a
reasonable time then investigate the other high priority
process.

Dave

Re: Login with a high priority

Kris Clippeleyr — Thu, 21 Apr 2005 02:45:00 GMT

Wim,

What we use over here is what we call the "noodrem" (emergency break in English).
We define a dedicated LAT service on each node bound to a LAT port.
We then start a detached process (with prio 20) that listens on the LAT port.
Whenever someone tries to connect to the service, the process prompts for a password and if valid lets the user in, and goes into dialogue with her/him, executing whatever DCL command is given.

Using this mechanism we were able to intervene even on systems that had CPU eating (application) processes at prio 15.

Hope this helps,
Kris (aka Qkcl)

Re: Login with a high priority

Wim Van den Wyngaert — Thu, 21 Apr 2005 02:52:22 GMT

David

I thought of that. But what about detached processes that don't execute login.com ?
I also dont't want to be in high prio during login unless I need it.

No. Now you can do username/cli/disk/table/new_pass (help login). I hoped on something like /prio= to be undocumented.

Wim

Re: Login with a high priority

Wim Van den Wyngaert — Thu, 21 Apr 2005 02:58:26 GMT

Very nice Kris. No problem with LATACP only running at 12 ?
Another solution could be that a system parameter indicated the priority of a console login. Of course this would be no solution for work stations.

Wim

Re: Login with a high priority

David B Sneddon — Thu, 21 Apr 2005 02:59:39 GMT

Wim,

Maybe I have misunderstood your problem?
You encounter a need to login because of a looping process.
You attempt an interactive login but it takes too long
because of this looping process.
You want to be able to login quickly to investigate the
looping process.
If you have "special" username for this purpose with a priority
of 16 in the UAF then you will be able to do this.
I don't understand the reference to detached processes and
the use of login.com

Dave

Re: Login with a high priority

Willem Grooters — Thu, 21 Apr 2005 03:00:49 GMT

Elevating base priority in SYSUAF won't help. It's the login process that is started on unsolicited input that needs to get high priority. That constitutes a problem, if I deduct from what I hope recall correctly:
Since a new process is considered to reside in state COMO (outswapped), SWAPPER is involved in creating the process - and SWAPPER runs in prio 16....
Nor would it help much if the runaway process runs on even higher priority. You would face the same problem, if not worse, since SWAPPER wouldn't even be able to swap the process in!

The _only_ solution would be a redesign of the whole login process, bypassing swapper. I don't think THAT is a reasonable solution.

As an alternative, you _could_ think of a (high priority), memory resident listener process you could connect to, that allows you to do the things you need to do (login, for instance).

Willem

Re: Login with a high priority

Volker Halle — Thu, 21 Apr 2005 03:03:09 GMT

Wim,

LOGINOUT is started using a base priority of DEFPRI (SYSGEN parameter) - hardcoded.

You could suppress execution of your LOGIN.COM using /NOCOMMAND (i.e. enter Username: wim/NOCOMMAND) - saving some time.

Or have an 'emergency' account with higher base prio in SYSUAF.

Maybe consider to play with Loginout callouts ?

If AMDS can't reduce the priority of the looping process, then nothing else can. As indicated by STOP/ID failing to stop your looping process as well.

Volker.

Re: Login with a high priority

Ian Miller. — Thu, 21 Apr 2005 03:18:40 GMT

I use AMDS to lower the process priotiy to 0 then I login normally and investigate. On one system I worked on the console used to be left logged on as a user with a elevated base priority - the console was in a locked room.

Re: Login with a high priority

labadie_1 — Thu, 21 Apr 2005 03:47:53 GMT

I try to always have a decterm logged in with a set proc/prio=high issued.

Re: Login with a high priority

Wim Van den Wyngaert — Thu, 21 Apr 2005 05:08:43 GMT

Just noticed : rlogin doesn't use the prio out of the sysuaf.
And with DCL it is difficult to generate a real cpu loop that makes login slow.

Re: Login with a high priority

Volker Halle — Thu, 21 Apr 2005 06:00:29 GMT

Wim,

rlogin doesn't use the prio out of the sysuaf.

What observation makes you say this ?

And with DCL it is difficult to generate a real cpu loop that makes login slow

Just set the base priority of your DCL loop process at real-time prioriy (16 or higher), this will prevent any process getting scheduled at a lower prio. Make sure you do this on a test system and then try to reduce the prio with AMDS.

WARNING: a looping process at prio 16 or higher will prevent ALL other processes from getting scheduled. It will effectively make your system appear 'hung', driver activity, cluster-connections etc. continue to work. As should AMDS !

Volker.

Re: Login with a high priority

Wim Van den Wyngaert — Thu, 21 Apr 2005 06:17:51 GMT

Volker,

I did a show proc after login. All sessions via decnet and lat have 20. rlogin only 4.

I tried jobs at prio 18 with a search command in a loop. After 15 batch jobs it was still not as slow as I was looking for.

But I left it running for some time and eventually it was very slow. But before that, I could do logins without any problem (taking 30 sec = 3 minuts).

There was no big difference in login time between a user with base prio 20 and 4 (in sysuaf).

I tested on an alpha 500 with VMS 7.3 and 8.2.

Wim

Re: Login with a high priority

David B Sneddon — Thu, 21 Apr 2005 06:21:02 GMT

If you want a DCL example...

In a decterm session
$ create cpuhog.com
$loop: goto loop
^Z
$ set process/priority=12
$ @cpuhog

This will slow it down
(I have tried this. To exit just ^C)

Dave

Re: Login with a high priority

Volker Halle — Thu, 21 Apr 2005 06:23:50 GMT

Wim,

so RLOGIN does not seem to go through SYSUAF.

If you use SEARCH to produce a 'loop', your process will do enough IOs and wait at LEF to get other processes a chance to run. If you would just program a DCL loop like:

$ loop:
$ GOTO loop

at prio 16 or higher, you would lock out your system. But it would be a good test case for AMDS ;-)

Volker.

Re: Login with a high priority

Ian Miller. — Thu, 21 Apr 2005 06:26:31 GMT

a search command in your dcl loop will do I/O and therefore will allow user processes to use the cpu while its waiting for the I/O to complete. Try
$L1: GOTO L1
at priority 18

Re: Login with a high priority

Wim Van den Wyngaert — Thu, 21 Apr 2005 06:45:48 GMT

To get a good cpu loop the label and goto need to be on 1 line. And yes, it loops.

Prio=4 process didn't get 1 cycle.

Prio=20 sessions did (of course).

The reset button of the 500 stopped functioning.

AMDS was able to lower the priority.

Wim

Re: Login with a high priority

Hein van den Heuvel — Thu, 21 Apr 2005 08:20:54 GMT

btw... low priority processes can significantly reduce the login time for high priority processes if they happen to be holding a bucket lock on sysuaf or rightlist.
Typically you'd see this with batch jobs calling vmsmail.

Some high priority looping jobs may pre-empt the CPU fom a batch job holding a critical lock giving it no opportunity to release it again, hurting a third process trying to login.

RMS bucket locks are transitory, and will come and go as needed without process control, but it does require cpu cycles to make them go.

Sysgen param pixscan tries to address this, giving low priority jobs an occasional priority boost.

If such lock is slowing you down (but admittedly it does not sound applicable here), then global buffers on sysuaf/rightslist may help because as of 7.3-2 ? those will also enable concurrent reads on buckets!

Maybe I should point out that newadditional benefit in: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=861351

fwiw,
Hein.