On 08.03.2014 02:13, Brian Dockter wrote:
On Fri, Mar 7, 2014 at 3:36 PM, Michael Friedrich
<michael.friedr...@gmail.com <mailto:michael.friedr...@gmail.com>> wrote:
On Fri, Mar 7, 2014 at 12:59 AM, Gunnar Beutner
<gunnar.beut...@netways.de <mailto:gunnar.beut...@netways.de>
<mailto:gunnar.beut...@netways.de
<mailto:gunnar.beut...@netways.de>>> wrote:
That's a bug (https://dev.icinga.org/issues/5721) which
I've just
fixed
in the Git repository. Can you re-test this using the snapshot
RPMs please?
I've moved over from the release repository to the snapshot
repository. Once there, I did a:
yum remove icinga2.x86_64 icinga2-common.x86_64
(which also removed icinga2-ido-mysql), followed by a:
yum install icinga2-0.0.7-snapshot201403071522.el6.x86_64
icinga2-ido-mysql-0.0.7-snapshot201403071522.el6.x86_64
icinga2-common-0.0.7-snapshot201403071522.el6.x86_64
I'm now getting the following error in the log:
[2014-03-07 10:35:55 -0800] <WQ #3> critical/db_ido_mysql:
Exception during database operation:
/home/abuild/rpmbuild/BUILD/icinga2-abuild/components/db_ido_mysql/idomysqlconnection.cpp(290):
Throw in function icinga::IdoMysqlResult
icinga::IdoMysqlConnection::Query(const icinga::String&)
Dynamic exception type:
N5boost16exception_detail10clone_implIN6icinga14database_errorEEE
std::exception::what: std::exception
[PN6icinga10StackTraceE] =
(0) libdb_ido_mysql.so:
icinga::IdoMysqlConnection::Query(icinga::String const&)
(+0x501) [0x7f34c5372971] (??:0)
(1) libdb_ido_mysql.so:
icinga::IdoMysqlConnection::Reconnect() (+0xa79)
[0x7f34c5376869] (??:0)
(2) libbase.so: icinga::WorkQueue::WorkerThreadProc()
(+0x56f) [0x7f34c698a9af] (??:0)
(3) libboost_thread-mt.so.5: thread_proxy (+0x77)
[0x3b99a0ad47] (??:0)
(4) /lib64/libpthread.so.0() [0x307e0079d1]
(5) libc.so.6: clone (+0x6d) [0x37c28e8b6d] (??:0)
[PN6icinga12ContextTraceE] =
(0) Reconnecting to MySQL IDO database 'ido-mysql'
[PN6icinga16errinfo_message_E] = Data too long for column
'agent_version' at row 1
[PN6icinga23errinfo_database_query_E] = INSERT INTO
icinga_conninfo (instance_id, connect_time, last_checkin_time,
agent_name, agent_version, connect_type, data_start_time)
VALUES (1, NOW(), NOW(), 'icinga2 db_ido_mysql',
'v0.0.7-54-g14d8f8a', 'INITIAL', NOW())
I took a look at the mysql schema and it still says that
agent_version is varchar(16). Should I alter the table or is
there a different solution?
Open a ticket please, and also provide an alter statement then
please (mysql and pgsql preferred). Seems it was designed only for
x.yy.zzz versions which is obviously bullshit.
I've opened a bug and provided an alter statement for MySQL. I don't
have Postgres installed anywhere currently.
My agent_version problem is solved, but I'm now seeing the following
in the logs:
[2014-03-07 16:51:00 -0800] <WQ #3> critical/db_ido_mysql: Exception
during database operation:
/home/abuild/rpmbuild/BUILD/icinga2-abuild/components/db_ido_mysql/idomy
sqlconnection.cpp(290): Throw in function icinga::IdoMysqlResult
icinga::IdoMysqlConnection::Query(const icinga::String&)
Dynamic exception type:
N5boost16exception_detail10clone_implIN6icinga14database_errorEEE
std::exception::what: std::exception
[PN6icinga10StackTraceE] =
(0) libdb_ido_mysql.so:
icinga::IdoMysqlConnection::Query(icinga::String const&) (+0x501)
[0x7f052bcf4971] (??:0)
(1) libdb_ido_mysql.so:
icinga::IdoMysqlConnection::InternalExecuteQuery(icinga::DbQuery
const&, icinga::DbQueryType*) (+0x60a) [0x7f052bcf715a] (??:0)
(2) libbase.so: icinga::WorkQueue::WorkerThreadProc() (+0x56f)
[0x7f052d30c9af] (??:0)
(3) libboost_thread-mt.so.5: thread_proxy (+0x77)
[0x3b99a0ad47] (??:0)
(4) /lib64/libpthread.so.0() [0x307e0079d1]
(5) libc.so.6: clone (+0x6d) [0x37c28e8b6d] (??:0)
[PN6icinga12ContextTraceE] =
[PN6icinga16errinfo_message_E] = Unknown column 'icinga_node' in
'field list'
[PN6icinga23errinfo_database_query_E] = INSERT INTO
icinga_notifications (contacts_notified, end_time, end_time_usec,
escalated, icinga_node, instance_id, long_output,
notification_reason, notification_type, object_id, output, start_time,
start_time_usec, state) VALUES ('1', FROM_UNIXTIME(1394239860),
'601969', '0', 'build-icinga', 1,
'', '0', '1', 35, 'PROCS CRITICAL: 655 processes',
FROM_UNIXTIME(1394239860), '601969', '2')
It appears that the icinga_node field was added since 0.0.7 (even
though the dbversion has not changed), but it was not part of the
0.0.8 upgrade script that is present in the snapshot.
I'll open a bug and check into any other schema differences that may
be present.
That's merely the problem that i am not able to merge
feature/db-endpoints-5636 at this point as it's not finished.
'icinga_node' was temporarly available with 0.0.7 but has been reverted
in favor of endpoint object ids. 0.x.y is a constant work in progress,
keep that in mind.
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
--
DI (FH) Michael Friedrich
michael.friedr...@gmail.com || icinga open source monitoring
https://twitter.com/dnsmichi || lead core developer
dnsmi...@jabber.ccc.de || https://www.icinga.org/team
irc.freenode.net/icinga || dnsmichi
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
