How to fix the base priority for a captive account user in VMS

[Sk Noorul Hassan]

Hi all,

There is a captive account in my VMS box. Once he logs in a process is created in his user name. I want to fix the priority of that process to 4.

Please suggest

[Volker Halle · Accepted solution]

Hi,

UAF> MOD username/PRIO=4

will set the base priority of processes created by this user to 4.

Note that OpenVMS applies priority increments based on certain events (like IO completion). You can not disable this feature on a per-user base.

Are you trying to solve a specific problem ?

Volker.

[Sk Noorul Hassan]

Thanks Volker,

The user was running some report, some how it went to cpu hungry mode & resulted in system lock up. But this happened for the first time. is there any way to get rid off. I found the user name in crash dump( SDA>sho process command).
Am I right?

[Joseph Huber_1]

Note the base_prio 4 is default for all users.
So if You want this captive user run at lower priority, put a 3 or 2 for them.

A better solution probably would be to rewrite the captive procedure to force the CPU hungry program to lower priority (submit to batch, then SYNCHRONIZE).

[Jan van den Ende]

Hassan,

"a captive account user" "was running some report"

So, this report is somehow started from a procedure that is activated by some command procedure.
Locate that procedure, and just before starting the malicious report, add

$ SET PROCES/PRIO=0

Now, the report processing will only run when no other process is asking for the CPU.
Usually, the impact on the report processing running time will not be that big, but all other processes WILL notice!

And directly AFTER the reort is finished, reset things by

$ SET PROCES/PRIO=4

Note, that for priority setting HIGHER than specified in SYSUAF the account needs privilege ALTPRI, but LOWER settings and re-setting are always allowed.

hth

Proost.

Have one on me.

jpe

[Volker Halle]

If you are afraid, that this could happen again, you could lower the base priority of this user (even as low as priority 0).

A process looping at priority 4 should not cause the system to lock up. It may be holding some locks and not releasing them, causing other processes to block.

If you have forced a crash - a very good step enabling you to do further offline troubleshooting - you need to first locate the user's process in the dump.

Start with SDA> SHOW SUMM

If you find a process with this username (and it's the only process running under that user), this process should also be in CUR or COM state - if it's CPU-bound, as a looping process would be.

Set context to that process SDA> SET PROC

Check the accumulated CPU time, there should be a high value:

SDA> SHOW PROC/PHD
... Accumulated CPU time 000000E7
...

Next check, whether this process has any busy channels or is holding any locks:

SDA> SHOW PROC/CHAN

... any channel 'busy' ?

SDA> SHOW PROC/LOCK

... is the first lock (or any other lock) shown in Waiting for... ?


Now check the rest of the processes for unusual status (like RWxxx or such).

Report what you've found (maybe attach the SDA output as a .TXT file) and then we'll consider the next step...

Volker.

[Sk Noorul Hassan]

Volker,
Please find the SDA output attached. User name is TELECOMMS.

[Volker Halle]

The TELECOMMS process only has accumulated about 7.8 CPU seconds (0000030C) by the time you've forced this crash, so I doubt that it really was CPU-bound for an extended amount of time. No busy channels, no waiting locks.

What I'm curious about are all those processes in PFW state (Pagefault Wait).

You can find out, how long a process is waiting in it's current wait queue with:

SDA> READ SYS$SYSTEM:SYSDEF

SDA> SET PROC /ID=
SDA> eva ((@exe$gl_abstim_tics)-@(pcb+pcb$l_waitime))

This will give the wait time in 10ms ticks. Try to find a PFW process, which is waiting for a really long time.

What does SDA> EXA EXE$GL_FLAGS report ?

What made you decide to force a crash ? What did you see in the system at that time ? How long did you wait, before you decided to force a crash ?

Crashdump analysis is not trivial. Analyzing a forced crash may be even more complicated. You need to find something, e.g. some 'hanging' operation, from where you start your analysis.

Volker.

[Volker Halle]

Oh, ERRFMT is in LEF - it should normally be in HIB !

Please check whether ERRFMT has any busy channels or waiting locks. Also please check, the waitime for this process.

Does SDA> SHOW DEVICE DI or DK show any non-zero error counts on the disks ?

I guess you do not have the console output available, otherwise this could be helpful as well.

Volker.

[Volker Halle]

... and JOB_CONTROL and QUEUE_MANAGER are in LEF, so we at least haev something to start at...

Possibly anything wrong with the system disk ? Or with the disks containing SYSUAF or queue manager files ?

Volker.

[Sk Noorul Hassan]

Volker,

Thanks..

We waited for almost 10 mins before forcing the server to crash, as the users were not able to work & console was not responding . The server locked up completely and was not responding.

Please find the SDA output for ERRFMT process as asked

[Ian Miller.]

looks like DIA0 is in mount verify state and there are several I/O requests queued.

If you do a CLUE ERRLOG command in SDA this will extract the unwritten error log buffers to a file called CLUE$ERRLOG.SYS which can then be looked at using your usual error log formatting tool (ERF, DECevent, WEBES).

[Richard Brodie_1]

"looks like DIA0 is in mount verify state".

Is it really in mount verification, or is the system not processing I/O to it for some other reason?

[Ian Miller.]

my mistake. I misread the mountver flag in the VCB - it actually means "subject to mount verification" not mount verify in progress.

Certainly something is causing problems with processing I/O to that disk. See the unwritten error log buffers would be interesting.

The results of
SHOW RESOURCE/LOCKID=1F00023B

would be interesting
[to show who has the volume lock on the system disk that ERRFMT is waiting for]

[Sk Noorul Hassan]

Hi,

Please find the output attached as asked.

[Ian Miller.]

and whats the result of
SHOW LOCK 4900091A
[this is the granted lock for the system disk volume].

Did you get the error log buffers with CLUE ERRLOG ?

[Volker Halle]

This node is most likely a VAX, so to extract the errlog entries from the crash, one needs to do:

$ CLUE:==$CLUE
$ CLUE/ERROR_LOGS SYS$SYSTEM:SYSDUMP.DMP

This command will extract the errlog entries from the crash into a file called CLUE_ELOG.SYS - use ANAL/ERR CLUE_ELOG.SYS to translate the errlog entries.

As you can see, ERRFMT has a busy IO to the disk DIA0 (probably the system disk). Many other IOs are pending on this disk, the oldest one is a DSE (data security erase) IO (from JOB_CONTROL).

ERRFMT is also waiting for the volume lock F11B$vSYSTEM of this disk, this lock is blocked by a PW lock with the lock-ID 4900091A. If you provide SDA> SHOW LOCK 4900091A, we can find out which process is associated with this blocking lock and what state this process is in.

As I said, a forced crash analysis is a step-by-step process, but it will lead you nearer to identifying the problem...

Volker.

[David B Sneddon]

Just having a very quick look at the attachments,
I notice a batch job running... is it possible
to see what this job is doing?
Could it possibly be doing an ANALYZE/DISK and
trying to output its logfile data to the disk
it is repairing? This will cause the type of
lockup seen here.

Dave

[Volker Halle]

If Dave is right - and this looks like a possible explanation - then the blocking lock should be hold by that batch job...

If you've shown the lock 4900091A, look at the PID of the lock and examine the process pointed to by that pid:

SDA> SHOW PROC/ID=
SDA> SHOW PROC/CHAN
SDA> SHOW PROC/IMAGE

Volker.

[Sk Noorul Hassan]

Thanks..

I did the following in server,
$ CLUE:==$CLUE
$ CLUE/ERROR_LOGS SYS$SYSTEM:SYSDUMP.DMP
I am not getting CLUE_ELOG.SYS file.

For other information as asked, please find the attached file.

[Volker Halle]

JOB_CONTROL (pid=0001000B) is holding the Volume Allocation Lock on the system disk in PW mode. This lock controls allocation of free space and file IDs. It is a central lock for accessing the disk. This PW lock held by JOB_CONTROL will prevent all file system operations to this disk.

JOB_CONTROL has busy IOs to the system disk, JOB_CONTROL owns the most recent pending IO (dse).

There is a problem with DIA0, it's RwaitCount is > 0 - so there is some problem preventing IOs from being serviced. As this is a DSSI disk, there could be a problem with the MSCP connection to the ISE (embedded controller in the DSSI disk).

Please report the wait time of this process:

SDA> SET PROC /ID=
SDA> eva ((@exe$gl_abstim_tics)-@(pcb+pcb$l_waitime))

If the time is about 10 minutes, then you've found the process blocking access to your system disk.

Do you get any error message, when using CLUE/ERROR_LOGS ? Errlog entries should also have been copied to the system's ERRLOG.SYS, so please do ANAL/ERR/SINCE=15-minutes-before-crash-crash/before=5-minutes-after-forced-crash

Trying to find out, where the current IO is stuck and whether it's a SW or HW problem in the drive, may become complicated, but I would currently assume, that there was some problem with access to your DSSI system disk.

Volker.

[Sk Noorul Hassan]

Volker,

Please find the output for wait time. I am not getting any output for the period in error log.

[Volker Halle]

With CLUE you looked at the errlog entries of an Operator Shutdown dumpfile from 24-AUG-2006. Please try to issue the CLUE/ERROR_LOGS command against your forced crash dump (the one you are reporting the SDA output from).

The EXE$GL_FLAGS output value reported earlier shows no problems with pool or page/swap file usage.

Volker.

[Wim Van den Wyngaert]

Did you notice
00000217 0017 MC32_SERVER MC32 CEF 5 878B2E40 8D715C00 129

Why is it in common event flag wait ?

Wim

[Richard Brodie_1]

What happened to the BUFIO count for JOBCTL, I wonder?