[Pkg-nagios-devel] Bug#311695: Rather difficult to reproduce

Andres Salomon Andres Salomon <dilinger@debian.org>, 311695@bugs.debian.org
Fri, 03 Jun 2005 10:16:31 -0400


On Thu, 2005-06-02 at 21:25 -0700, Don Armstrong wrote:
> [Just to reiterate what we discussed on IRC for those following along
> at home.]
> 
> On Fri, 03 Jun 2005, Andres Salomon wrote:
> > Nope; nagios's resource.cfg was totally unconfigured. What I suspect
> > (I can tell you for sure tomorrow, when I'm at work) is that one of
> > the default mysql users (the '' user) was not removed; so, nagios
> > could connect with user '', and no password. Just doing a fresh
> > mysql-server install and a nagios-mysql install gets me:
> > 
> > Jun  2 23:56:10 spiral nagios: Error: Could not lock status data tables
> > in database ''
> > Jun  2 23:56:40 spiral last message repeated 2 times
> > Jun  2 23:57:40 spiral last message repeated 4 times
> > 
> > Same type of error, though not nearly as frequently.
> 
> You couldn't get this unless you allow a blank user to connect to
> mysql, which isn't the default configuration of mysql-server.
>  
> > Only if you've modified the mysql.user table to not accept a blank user.
> 
> By default, the only users are 'root' and 'debian-sys-maint'.
> 

Ah, I knew I remembered the blank user from somewhere (and here I
thought I was imagining things).  At least on woody, installing
mysql-server will get you 'root', 'debian-sys-maint', and ''.  Helmsley
was originally a woody box, and thus has the blank user.

The fact that I can make this happen w/ sarge's mysql-server, which has
no '' user, doesn't change my opinion of the RC-ness of this bug.

What actually made nagios loop w/ so many attempts, however, I'm still
not sure.  I'd rather see this fixed for sarge because, well.. the
default behavior is just *stupid*.  Even a sleep(1) before that continue
would be saner behavior than just looping as fast as possible.

Don's fix is incomplete, I believe; there is another function which does
the same thing that should be fixed.  xrddb_save_host_information will
no longer infinitely loop, and just return.  However, the next function
to be called will be xrddb_save_service_information, which has the same
construct; thus, it will simply loop endlessly, instead.  That
'continue;' should also be commented out (line 741).  I'm also
questioning the validity of still running xrddb_commit_transaction(),
even if a mysql error has occurred.  Perhaps instead of just continuing
to iterate over the hosts and services, the functions should instead
just return ERROR; immediately?