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 [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
