Login problem

[Willem Grooters]

We just had a weird problem, probably concerning SYSUAF.DAT and LOGINOUT.EXE on a OpenVMS 7.3-1 development system. All developers have default TMPMBX and NETMBX privileges, but most are authorized for all for team-related system managemnat tasks (we trust eachother ;-)). This normally is no problem at all, but once is a while there is some error in synchronisation.
Like this time:
One user is setting up a test account, and logs in a number of sessions of this account from a PC (Telnet).
During this, another user is changing this account's password and login information (flags, eventually) and updated SYSUAF.
What happened next is that some way the login stopped responding, appearently looping, causing trouble to login, even for the real system manager. He finally could stop all processes of this user, but one, since that remained in RWMBX state. There was no way to stop this process except for rebooting (we could have tried sending a message to the mailbox, but that would have taken more time).

What worries me is the fact that SYSUAF can be updated and at the same time, this record-in-update can be used by LOGINOUT to create a proces and assign it to a user. I would thing that AUTORIZE would need to lock the record of a user, as soon as it is accessed for update, and that LOGINOUT.EXE - in fact: any program requiring access - would signal the record locked.

[Ian Miller.]

Do you know which mailbox the process in RWMBX?

Di you look at the locks on SYSUAF at the time?

[Willem Grooters]

No - alas - the system was rebooted before I could get hold of that data.
The process in RWMBX state was one of those test processes. So I guess it had to do with some synchronisation problem with SYSUAF. (No evidence, just the feeling).
Perhaps I could try to reproduce ;-) but it might have been one of those very particular, unusual situations where miliseconds can make a differece, so that is a challenge in itself.

[Ian Miller.]

It could have been JOB_CONTROL mailbox or AUDIT_SERVER mailbox I suppose. I guess going into AUTHORIZE then looking using SDA from another process to see what locks exist might be interesting or a look through the listings for AUTHORIZE to see what RMS calls it does.

[Willem Grooters]

Audit, likely. SYSUAF is audited.

The issue proved to be a bit different, getting deeper into the matter (that is: interrogating the culprits :D). The first user used Authorize to set passwords for a number of people, and at one point, when hitting return after UAF> MOD /PASS=, his session froze.
Another person was than asked to chnage that password but his session froze as well. ^C freed that session, but the first remained unaccesable due to RWMBX.

After reboot, there was no problem (of course) of accessing that SYSUAF record and the password could be set.

I may take a look into the audit log, and accounting. If the auditserver died for some reason, there should be an entry ein either one of them.

[Jan van den Ende]

Willem,

little chance on ACCOUNTING. Those records are written at proces and, but your culprit process did not end. It was taken down with the system...

And do not yet disqualify JOB_CONTROL. That one also does use SYSUAF (and RIGHTSLIST) for various functionalities.

But I also do not have an answer...

Proost.

Have one on me.

jpe

[Arch_Muthiah]

Williem,

MAIL is one of the applications that will always hold SYSUAF open.


Archunan

[John Gillings]

Willem,

I suspect this was a resource issue, rather than an RMS timing bug. If it happens again, please look at the RWMBX process to see what it's waiting for.

That the process is in RWMBX state means it's trying to write to a mailbox, NOT accessing an RMS file. Of course, if it has a lock on a record within a file, other processes may block on that lock.

>There was no way to stop this process
>except for rebooting (we could have
>tried sending a message to the mailbox,
>but that would have taken more time).

Nonsense! RWMBX is EASY to fix, just find the mailbox and READ from it:

$ COPY MBA1234: dump.dat

The mailbox itself should be immediately obvious from SDA> SHOW PROCESS/CHANNEL

If it's not obvious, there is one other way a process can get into RWMBX - if you block output on OPA0: for a very long time (like weeks!)

[Ian Miller.]

"The mailbox itself should be immediately obvious from SDA> SHOW PROCESS/CHANNEL"

not always as there may be multiple mailboxes which are shown. To definitively find which mailbox then you have to look at the register values for the process. One of them will contain a channel number of a channel assigned to a mailbox. That is the mailbox the process is waiting for. On VAX/VMS then register R5 contains the UCB address of the mailbox.

Or use PWAIT SDA extension which does this for you.
http://eisner.encompasserve.org/~miller/pwait_sda00d.zip

[Willem Grooters]

We might look into AUDIT SERVER - one more candidate. Auditing is set ON on changes of SYSUAF and it might well have been that the AUDITSVR process was gone - there are some vague rememberances of that.
However, we now have some idea where to look next time.