Re: [Help-gnunet] Database corrupted

[Christian Grothoff]

On Wednesday 28 April 2004 15:37, Ludovic Courtès wrote:
> Hi,
>
> I'm using GNUnet 0.6.1d (from Debian unstable), with a gdbm database.
> Since I upgraded from GNUnet 0.6.1b, my database since to be corrupted
> (maybe this has nothing to do with the upgrade, though), ie. `gnunetd'
> logs lots of things like:
>
>   WARNING: pIdx database corrupt (could not unlink 5A9EED9B3297D1C
>   27EFD6545760F8C025E6EBBCE from low DB (69199, 4940, 26))
>
> Most of the time, gnunetd "disappears" (it does not dump core so maybe
> that is "normal" behaviour) a few minutes after it started.  More
> precisely, it seems to stop after an initial high disk activity (I guess
> gnunetd starts by "browsing" the database or so and then normally stops
> doing lots of disk accesses and starts doing "the real job", right?).

First I'd suggest looking at the log (~/.gnunet/log).  Also you can try 
starting gnunetd with "-d -L DEBUG" in which case the error messages are 
printed to the terminal (gnunetd won't daemonize with "-d").

> Anyway, I thought I might clean the database since running
> `gnunet-check -a' did not fix the problem.

Well, cleaning the database is definitely one solution, but the better 
solution is to first get a better handle on why it does not work. I'd first 
try with looking at the error message as described above.

> However, I noticed that 
> `gnunet-directory -A', for instance, does nothing, and `gnunet-directory
> -a' doesn't show any entry.  Am I missing something?  Is entirely
> removing the `data' directory and then re-inserting content a relevant
> option?

Yes, you're missing the all important "COLLECT-FILE-IDENTIFIERS" option in 
section [AFS].  If that is not set to "YES", GNUnet will *not* record 
RBlocks.

> BTW, unlike stated by the help message, `gnunet-directory' does not
> support the `-V' and `--verbose' options.

That can be fixed right away... :-).

Christian