Re: [Help-gnunet] GNUnet 0.7.2a released

[Christian Grothoff]

On Tuesday 10 July 2007 15:13, David Kuehling wrote:
> >>>>> "Christian" == Christian Grothoff <address@hidden> writes:
> >
> > I wonder how you managed to restart gnunetd without gnunet-update --
> > the code does check.  The only way I can think of this happening is
> > that you might have started gnunetd with a different directory /
> > configuration.
>
> Running gnunet-update, I just saw the following message:
>
> Jul 10 22:55:45 ERROR: `mysql_query' failed at mysql.c:1542 with error:
> Lost connection to MySQL server during query
>
> I also remember having seen the same message when running gnunetd
> v0.7.2a the first time.  Does this point to a specific problem?

Well, it means that the mysql daemon died or that there was a timeout.  Sadly, 
despite the MySQL documentation stating otherwise 
(http://dev.mysql.com/doc/refman/5.0/en/gone-away.html), I've not been able 
to get mysqld to log the specific cause of the disconnect (log-warnings=2 
does not help), no matter what I've tried (we increased some timeout values 
to make it happen less often, but that does not mean that the problem went 
away).

Anyway, in theory gnunetd automatically re-connects as needed and all is well. 
In practice, depending on how you have configured mysqld (in, 
say, /etc/mysql/my.cnf), there maybe other issues like exceeding the number 
of connections with the daemon (I've explored some rather extreme 
configuration options that caused this error to happen all the time).  So 
yes, it points to an error.  GNUnet does what it can to recover, fixing it 
for real would require mysql to provide reasonable diagnostics, which on my 
system it does not.  

The problem seems to arise only  for large InnoDB databases (mine had grown to 
15 GB!), and I've read that InnoDB has "known scalability problems".  So 
maybe that's the issue, hard to say -- I'm not that deep into MySQL database 
tuning.  

Hope this clears things up somewhat.

Christian