[Pkg-nagios-devel] Bug#289762: nagios-mysql bugs

Jeroen van Wolffelaar Jeroen van Wolffelaar <jeroen@wolffelaar.nl>, 289762@bugs.debian.org
Fri, 14 Jan 2005 03:16:24 +0100


severity 289762 grave
tags 289762 - moreinfo
thanks

On Wed, Jan 12, 2005 at 01:57:22AM +0100, Georg Sorst wrote:
> Hi,
> 
> I've experienced the very same problem as described above where nagios
> is not able to update the database. This can be easily fixed by removing
> all the "NOT NULL" entries
> from /usr/share/doc/nagios-mysql/create_mysql.gz. While I cannot tell
> yet if this will have any effects on the functionality of nagios it will
> at least make it stop complaining.

Yeah, nagios tries to insert NULL's where that's imply not allowed,
which breaks it. The reason is that the newest MySQL gives 'null' on
FROM_UNIXTIME(0), while that was previously something else.

This seems to be like a bug, as nagios shouldn't try to insert dates on
the epoch in mysql, but rather actually just use NULL as what is natural
for 'unknown' or 'irrelevant', and the table definitions should allow
it. Unfortunately, having people upgrade table definitions is hard, as
they needed to make them manually. So, it might be worthwhile to instead
workaround to have nagios insert the magic value '0000-00-00 00:00:00'.
Ugly, but seems to me workeable.

Also noteworthy is that timezone conversion happens mysql-server side
this way, and this will quite likely give funny results during DST
change or general timezone change. Applications should really store UTC
dates...

Although email notifications of status changes do seem to work, the web
status interface is completely unuseable (i.e., empty with errors),
since the hoststatus table is empty.

I'm removing the moreinfo tag as the problem seems quite clear, and even
though you guys didn't break anything, it _is_ your problem now,
unfortunately.

--Jeroen

-- 
Jeroen van Wolffelaar
jeroen@wolffelaar.nl
http://jeroen.A-Eskwadraat.nl