(Illustration by Gaich Muramatsu)
On Wed, Oct 10, 2001 at 02:28:48PM -0400, Jan Harkes wrote: > On Wed, Oct 10, 2001 at 01:45:59PM +0200, Matthias Teege wrote: > > So I do an venus -init & wich works and then try again my cvsup command. > > > > The point, venus stopped working is always different and I can't find any > > hint in the venus.log. > > > > How do I debug such thing? > > Check the venus.log file, especially near the end. (probably in > /usr/coda/etc/venus.log. If it doesn't show anything interesting, start > venus with 'venus -init -d 10', then there should be a _lot_ more stuff > in the venus.log to the point that it actually becomes hard to notice > the interesting messages. I'll append the last 100 lines from venus.log. There you can see that all directorys under /coda has gone. I have also run venus under gdb with but I get no interesting message. It looks like that venus dont die but only the mounted files are gone. Sometimes I can shutdown venus successfully but a clean restart is impossible. Can It be an cache problem? I have two servers and in this case venus run on server 1 (scm) and the volume to write is on server 2. All files must write over network to server 2. So I setup a big cache (300000) on server 1 and start the cvsup. It runs for a while and then /coda went away. After I restart venus with init and all cached files are gone, I try it again and I get sometimes conflicts on one directory wich I cant repair because of "Cant allocate new repvol ...". So I have to wait untill the cvsup stops, clean the cache and try again. > However, if it really is a crash (null-ptr or something) the easiest > way that I've found is to run venus under gdb, which catches the > segfault and then grabs a stacktrace. No segfault at all but only on restart without init. There I get an 09:13:16 49884 CML entries allocated 09:13:16 0 CML entries on free-list 09:13:16 starting FSDB scan (12500, 300000) (25, 75, 4) 09:13:17 fatal error -- recovery failed on local, non-file object (gcc27, (0xffffffff.0xffffffff.0x2)) 09:13:42 Fatal Signal (11); pid 2609 becoming a zombie... 09:13:42 You may use gdb to attach to 2609 %vutil shutdown %09:15:46 RecovTerminate: clean shutdown Many thanks Matthias -- Matthias Teege -- matthias@mteege.de -- http://emugs.de make world not war PGP-Key auf Anfrage