Bug in Account Manager

[Karl Ian Ransome]

Annoying bug in Account Manager Modify User

SCO OS 5.0.2c, Pentium Pro, 4 x 200 mhz processors, RAID 5
Auditing not running. Using Account Manager on terminal or
console (not X window).

I modified 20 user accounts just by changing account path.
On 21st (number not significant) the **** kept going in top
left corner and did not return to Account Manager accounts list.
On doing ps the following showed:

dlvr_audit 857988450 12 25 2164 usershell 4 auth 17 16 0 3 /bin/sh

kill -9 PID brought back the usual accounts list. But the next
time I modified an account (even if I opened a new terminal!!!)
there were 4 processes to be killed in succession before I could
get back to the account names list. It of course takes more than
4 times the time to modify an account.

On Friday on one server I modified 69 accounts on one server without
problem yet on the other server after 17 modifications it gave the
dlvr processes. This morning I have shutdown and rebooted both
servers and now the server that was OK on Friday now falls over with
the above 20 users modified. How do I solve this or get around it.
It takes so much longer to modify or add accounts with having to
kill 4 processes off after each modification. Is there a fix for
this yet - I have not seen it in the FAQ or newsgroups.

Some cron jobs seem to die - the cpio tape backup did not begin
nor did the DLT backup since the problem on Friday. It means
shutdown and rebooting to get Account Manager and backup to work
again correctly - not exactly the method to please the users out
there. Any help would be greatly appreciated. This problem happens
on all three SCO 5.0.2c servers but not on the old 3.2r4.2 servers.

Karl Ian Ransome
Systems Manager
Scottish Agricultural Science Agency, Edinburgh
ran...@sasa.gov.uk

[Bela Lubkin]

Karl Ian Ransome wrote:

If you are intentionally using auditing, this is happening because the
auditing subsystem has gotten locked up somehow. But I think you
probably aren't using auditing.

In which case, this happens because the auditing system *thinks* it's up
and running, but it isn't. To correct the problem, remove the file:

/tcb/files/audit/audit_dmninfo

In fact, as far as I know, anyone who is *not* running auditing should
remove that file. (Test first, by moving it aside; run the system that
way for a few days.) This applies to SCO Unix 3.2.0 through OpenServer
Release 5.0.2.

>Bela<