Login with a high priority

[Wim Van den Wyngaert]

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

[Volker Halle]

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.

[Wim Van den Wyngaert]

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

[David B Sneddon]

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

[Kris Clippeleyr]

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)

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

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

[David B Sneddon]

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

[Willem Grooters]

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

[Volker Halle]

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.

[Ian Miller.]

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.

[labadie_1]

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

[Wim Van den Wyngaert]

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.

[Volker Halle]

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.

[Wim Van den Wyngaert]

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

[David B Sneddon]

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

[Volker Halle]

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.

[Ian Miller.]

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

[Wim Van den Wyngaert]

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

[Hein van den Heuvel]

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.

[Lawrence Czlapinski]

Wim, I have used AVAIL_MAN more than once to reduce or kill a priority 29 process on another cluster/system successfully. The priority 29 task occasionally gets in a continuous CPU mode. You do need control enabled in the node's security file. The advantage is that it is quick with no need to logon.
Lawrence

[Lawrence Czlapinski]

Wim, I have AVAIL_MAN running continuously while I'm at work. I usually detect the CPU hogs before I start getting calls from the users or application programmers. I have two groups: PRODUCTION and DEVELOPMENT. I have 15 nodes in the PRODUCTION group from 2 sites so I can see the CPU usage of all of them on the screen all at once.
Lawrence

[Phil.Howell]

Could you have a virtual terminal set up with a very long timeout and disconnect it?
Any login to the same username would then not have to to any process creation.
If you tried this and it still took a long time to login, it would point to a delay in login authorisation, possibly due to locks on sysuaf and rightslist (as mentioned by someone else)
Phil

[Lawrence Czlapinski]

Wim, the reason we started using AVAIL_MAN was because we had the problem of not being able to get in once our priority 29 process got stuck in a CPU loop.
Alternatives:
1. Keep a session open for the purpose of being able to change priority of a CPU runaway. Have a symbol defined to increase priority of the session.
User must have ALTPRI priv.
Still may not be able to get in even without having to login.
2. Keep a session open with a high priority exclusively for the purpose of being able to lower priority of a CPU runaway.
Lawrence

[Uwe Zessin]

Volker's warning is absolutely warranted. A cpu-bound process that runs at realtime priority is not subject to quantum-end processing. It will keep on running, even if there is another process at the same priority.

Reminds me a bit about the system management training I attended around 1986. The teacher said that one could set his priority to 16 and then he would 'always' get the CPU. Well, didn't take too long until all students were running at priority 31. And it took even a shorter time until the teacher had to reboot the poor VAX-11/730 :-(