Hello,

I have been observing the following behaviour. On the client side,

(root) some-client /root > au nu          
Your Vice name: codaroot
Your password: 
RPC2_Bind() --> RPC2_SUCCESS
Vice user: cgu
New password: k
New info: k
AuthNewUser() --> RPC2_DEAD (F)

On the server side, the auth2 daemons core dumps as a result of "au nu".
The /vice/auth2/AuthLog file reads:

Date: Wed 10/20/99

18:16:43 Reallocing from 100 to 1000
18:16:43 Server successfully started

18:16:54 In PWGetKeys()
18:16:54        vid = 500
18:16:54        vid = 500
18:16:54 AuthNewConn(0x1a9212ab, 0, 66, 2, 500)
18:17:06 In PWGetKeys()
18:17:06        vid = 500
18:17:06        vid = 500
18:17:06 AuthNewConn(0x3a8c9303, 0, 66, 2, 500)
/vice/db/auth2.lock: Bad file descriptor


Previous to the "au nu" call, I could an acquire tokens without
problems, that is clog succeeds.

A stack trace of auth2 gives,

(root) lamone /vice/auth2 >gdb /usr/sbin/auth2 core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `auth2          '.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libNoVersion.so.1...done.
Reading symbols from /lib/libdb.so.2...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
#0  0x400454e1 in __kill () from /lib/libc.so.6
(gdb) info stack
#0  0x400454e1 in __kill () from /lib/libc.so.6
#1  0x40045156 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x40046868 in abort () at ../sysdeps/generic/abort.c:88
#3  0x804ac2d in LockParent (fName=0x8060d08 "/vice/db/auth2.pw", lockType=1)
    at /usr/src/redhat/BUILD/coda-5.3.2/coda-src/auth2/pwsupport.c:158
#4  0x804b0ef in AppendPW (vId=779, eKey=0xbffffca0 "k", otherInfo=0x806c288 "k", agentId=500)
    at /usr/src/redhat/BUILD/coda-5.3.2/coda-src/auth2/pwsupport.c:319
#5  0x804b264 in PWNewUser (cid=982291203, viceId=779, initKey=0xbffffca0 "k", 
    otherInfo=0x806c288 "k") at /usr/src/redhat/BUILD/coda-5.3.2/coda-src/auth2/pwsupport.c:362
#6  0x804a0b4 in S_AuthNewUser (cid=982291203, viceId=779, initKey=0xbffffca0 "k", 
    otherInfo=0x806c288 "k") at /usr/src/redhat/BUILD/coda-5.3.2/coda-src/auth2/auth2.c:588
#7  0x804a6bc in _S_AuthNewUser (_cid=982291203, _reqbuffer=0x806c1b0, _bd=0x0) at auth2.server.c:270
#8  0x804a972 in auth2_ExecuteRequest (_cid=982291203, _reqbuffer=0x806c1b0, _bd=0x0)
    at auth2.server.c:391
#9  0x8049791 in main (argc=1, argv=0xbffffd54)
    at /usr/src/redhat/BUILD/coda-5.3.2/coda-src/auth2/auth2.c:179

The SCM is running RedHat 6.1, with Linux kernel 2.2.12-20. I seached
the mailing list to check if this was a known issue. Apparently
not. Regards, Ceki