(Illustration by Gaich Muramatsu)
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, CekiReceived on 1999-10-20 12:55:35