[dev.icinga.com #3399] FROM_UNIXTIME(NULL) does not work with MySQL 5.0.x #1146
This issue has been migrated from Redmine: https://dev.icinga.com/issues/3399
Created by gingernator007 on 2012-10-25 10:07:55 +00:00
After upgrading Icinga from 1.5.2 -> 1.8.0, IDOUTILS began outputting errors when trying to update the mysql db. I updated the schema incrementally as the instructions specified and shut down the Icinga service before doing so. Due to this Icinga Web can't pull the status of any of my hosts or services. Have I upgraded this incorrectly?
2012-11-28 14:53:21 +00:00 by mfriedrich 1042107
Updated by gingernator007 on 2012-10-25 12:22:24 +00:00
Thanks for the response, I've had to roll back the update due to this being our Production system, any ideas why this happened and how I can prevent it for the next attempt?
Looking back at the syslog, we have many other errors along the same lines...
Updated by newmanium on 2012-11-01 19:40:42 +00:00
I think I just encountered this same bug on my fresh 1.8 Icinga install. It looks timestamp fields are created NOT NULL by default in MySQL (at least 5.0+ from what I can tell). However, the CREATE statements in the schema sql script look like this:
Note that "NULL" is not specified in any of the timestamp columns, and they would therefore default to "NOT NULL" as per the MySQL documentation:
When I started up icinga with the idoutils module, I started getting a spamming of errors like this in my /var/log/messages:
So, this bugfix may be as simple as adding the word "NULL" to all the schema creation and update statements for timestamp columns. I set all my timestamp columns that were erroring in /var/log/messages to allow null values and things seem to be working fine meow.
Updated by iso on 2012-11-08 15:58:37 +00:00
Same for me today at a 1.7.2 upgrade to 1.8.1. Ugrading the mysql schema by
gave errors, continued with
which run without a comment. I now have a lot of
Updated by mfriedrich on 2012-11-08 16:25:56 +00:00
that script is not necessary to be run. you should have run that already when installing/upgrading to 1.7.x
which errors exactly?
Updated by iso on 2012-11-09 08:50:15 +00:00
Cannot remember the errors and the output is gone. I was a bit confused because I knew that I had to update the db scheme incrementally. Upgrading from 1.7.2 to 1.8.1 I was not sure about the 1.7.0 and 1.8.0 files.
Updated by iso on 2012-11-14 14:12:45 +00:00
I can reproduce this on a fresh installation. Syslog started to fill up as I activated the idoutils module confiuration. Without it I had all functionality I need, but no ido2db error logging.
I think that means I don't need idoutils and mysql? Weird...
Updated by mfriedrich on 2012-11-14 14:57:59 +00:00
idomod/ido2db is a requirement when using the database backend, which is a requirement for -web or -reports e.g.
deactivating the neb module (idomod) will break the communication of between core and ido2db, and therefore leaving ido2db idle doing nothing.
seems i need to get a centos 5.x virtualbox image somewhere in order to reproduce that.
Updated by aledermueller on 2012-11-16 07:17:04 +00:00
I think it is not a bug in the query or db schema, but rather in mysql. The mysql docs say:
"In addition, you can initialize or update any TIMESTAMP column to the current date and time by assigning it a NULL value, unless it has been defined with the NULL attribute to permit NULL values." 
FROM_UNIXTIME(NULL) gives back the value NULL and last_log_rotation is defined with 'not null', hence it should get a current time stamp.
We had the same problem on sles11 and with an update of mysql everything worked fine.
Updated by mfriedrich on 2012-11-25 23:44:33 +00:00
el5 is likely to die with the 5.0.x tree and will never provide any upgraded packages. though, i did not see such errors with my rhel 5.8 mysql 5.0.77 in the past. any chance that you check if there's a newer package revision available, maybe fixing the mentioned bug?
other than that, from what i've seen in the community, mysql 5.5 scales even better than 5.1 (ofc with some dba love too).
Updated by mfriedrich on 2012-11-28 14:52:08 +00:00
hm. Carl found an interesting one, which can be taken as reference to this issue - see #3466
So relating to that one, it's not a matter of upgrade cycles from 1.5.2 to 1.8.x, but only the FROM_UNIXTIME(NULL) change introduced in 1.8.0/1.8.1 which can be fixed by explicitely setting the null'ed timestamp then.
I expect #3466 resolving this issue as well, as it's merely a duplicate then.