Christian Grothoff a écrit : > The first time (this particular version of) gnunetd starts up (with sqlite > datastore) after an update, it needs to determine the actual size of the > datastore's entries (not just the filesize). For that, gnunetd does a full > scan of the sqlite database. If you abort gnunetd during that time, it will > restart the scan next time. Until that scan is complete, the file-sharing > subsystem won't be up and running. > I finally got out of this mess by waiting. Maybe I would be useful to add a debug level log saying that this check is starting and that it has finished, because for now you can imagine that is a long-run behavior of gnunetd.
Was that intended to be run only one time after an upgrade? Since I removed everything in /var/lib/GNUnet (letting /etc/gnunetd.conf), it looks like the check is performed from an empty database too. So maybe it would definitely be good to tell it to the user. > Depending on your database size and IO capabilities, that scan can take quite > a while. The stacktrace that you are reporting below shows gnunetd doing the > scan. > But even with a completely empty /var/lib/GNUnet/, gnunetd is seeking for several minutes, even if I can't imagine what it can read/write since the directory is only 4KB after some minutes of intense work. That's really strange. > I hope this helps... > Sure, thanks. Hope this may help too. PS: I'm currently working on our libgksu2 use in gnunet-gtk to make it comply with new options (since now you can choose a custom config file from the UI). I'll give you infos soon. _______________________________________________ GNUnet-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnunet-developers
