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 -- [email protected] -- http://emugs.de
make world not war
PGP-Key auf Anfrage