[dev.icinga.com #5632] hosts aren't included in hostgroups or at least that is not shown in the classic ui

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/5632

Created by gvegidy on 2014-02-10 21:45:47 +00:00

Assignee: gbeutner
Status: Resolved (closed on 2014-03-05 11:13:34 +00:00)
Target Version: 0.0.8
Last Update: 2014-03-09 12:48:41 +00:00 (in Redmine)

Icinga Version: icinga2-0.0.7

---

I'm using icinga2-0.0.7 and because of resource restrictions (it is running on a tiny Beaglebone Black ARM system) I'm running it with the classic ui.

I have the default configuration in generic-host.conf:

template Host "linux-server" inherits "generic-host" {
groups += [ "linux-servers" ],
...

But when I click on "Hostgroup Summary" in the Classic UI, I get shown "No matching hosts" although I have numerous hosts derived from "linux-server".

This is the same for other hostgroups too. If I explicitly add "groups = [ "xyz" ]" into the real host definition the problem stays the same.

So either the hostgroups don't work at all or aren't shown in the Classic UI anymore.

Attachments

• objects.cache gvegidy - 2014-02-11 21:54:25 +00:00
• status.dat gvegidy - 2014-02-11 21:54:31 +00:00

Changesets

2014-03-05 11:07:53 +00:00 by gbeutner 979d6cc

Fix: Host groups in objects.cache aren't working properly.

Fixes #5632

[icinga-migration]

Updated by gbeutner on 2014-02-11 12:11:45 +00:00

• Status changed from New to Feedback

Can you please attach a copy of your objects.cache and status.dat files to this ticket? They can usually be found in /var/cache/icinga2. Please note that both these files might contain confidential information about your infrastructure (such as host names, passwords, etc.) and you may want to sanitize them somewhat.

[icinga-migration]

Updated by gvegidy on 2014-02-11 22:07:21 +00:00

• File added objects.cache
• File added status.dat

Thanks for your quick reply. I've attached both files in shortened form. To me it looks like icinga2 isn't writing out the correct group information.

Please tell me if I have shortened the file too much to be of any use.

When looking into the logfile, I regularly see this error:

Feb 11 23:01:57 localhost icinga2: Exception during database operation: /root/rpmbuild/BUILD/icinga2-abuild/components/db_ido_pgsql/idopgsqlconnection.cpp(269): Throw in function icinga::IdoPgsqlResult icinga::IdoPgsqlConnection::Query(const icinga::String&)
Dynamic exception type: boost::exception_detail::clone_implicinga::database_error
std::exception::what: std::exception
[icinga::StackTrace*] =
(0) /usr/lib/icinga2/libdb_ido_pgsql.so: void boost::throw_exceptionicinga::database_error(icinga::database_error const&) (+0xc0) [0xb4b9bb10]
(1) /usr/lib/icinga2/libdb_ido_pgsql.so: void boost::exception_detail::throw_exception_icinga::database_error(icinga::database_error const&, char const**, char const**, int) (+0x4c) [0xb4b9bbe0]
(2) /usr/lib/icinga2/libdb_ido_pgsql.so: icinga::IdoPgsqlConnection::Query(icinga::String const&) (+0x2c4) [0xb4b8cf0c]
(3) /usr/lib/icinga2/libdb_ido_pgsql.so: icinga::IdoPgsqlConnection::InternalExecuteQuery(icinga::DbQuery const&, icinga::DbQueryType*) (+0x408) [0xb4b9162c]
(4) /usr/lib/icinga2/libdb_ido_pgsql.so: boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf2<void, icinga::IdoPgsqlConnection, icinga::DbQuery const&, icinga::DbQueryType*>, boost::_bi::list3<boost::_bi::valueicinga::IdoPgsqlConnection*, boost::_bi::valueicinga::DbQuery, boost::_bi::valueicinga::DbQueryType* > >, void>::invoke(boost::detail::function::function_buffer&) (+0x2c) [0xb4b92e18]
(5) /usr/lib/icinga2/libbase.so: icinga::WorkQueue::Enqueue(boost::function<void ()> const&, bool) (+0x294) [0xb6da7ce4]
(6) /usr/lib/icinga2/libdb_ido_pgsql.so: icinga::IdoPgsqlConnection::ExecuteQuery(icinga::DbQuery const&) (+0x1ec) [0xb4b8c648]
(7) /usr/lib/icinga2/libdb_ido.so: boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf1<void, icinga::DbConnection, icinga::DbQuery const&>, boost::_bi::list2<boost::_bi::valueicinga::DbConnection*, boost::arg<1> > >, void, icinga::DbQuery const&>::invoke(boost::detail::function::function_buffer&, icinga::DbQuery const&) (+0x24) [0xb4aba2ac]
(8) /usr/lib/icinga2/libdb_ido.so: boost::signals2::detail::signal1_impl<void, icinga::DbQuery const&, boost::signals2::optional_last_value, int, std::less, boost::function<void (icinga::DbQuery const&)>, boost::function<void (boost::signals2::connection const&, icinga::DbQuery const&)>, boost::signals2::mutex>::operator()(icinga::DbQuery const&) (+0x174) [0xb4ac472c]
(9) /usr/lib/icinga2/libdb_ido.so: icinga::ServiceDbObject::OnConfigUpdate() (+0x474) [0xb4aeb400]
(10) /usr/lib/icinga2/libdb_ido.so: icinga::DbObject::SendConfigUpdate() (+0x3f8) [0xb4acdda4]
(11) /usr/lib/icinga2/libdb_ido.so: icinga::DbConnection::UpdateAllObjects() (+0x148) [0xb4ab69c0]
(12) /usr/lib/icinga2/libdb_ido_pgsql.so: icinga::IdoPgsqlConnection::Reconnect() (+0xe4c) [0xb4b8f6b8]
(13) /usr/lib/icinga2/libdb_ido_pgsql.so: boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, icinga::IdoPgsqlConnection>, boost::_bi::list1<boost::_bi::valueicinga::IdoPgsqlConnection* > >, void>::invoke(boost::detail::function::function_buffer&) (+0x24) [0xb4b941bc]
(14) /usr/lib/icinga2/libbase.so: icinga::WorkQueue::WorkerThreadProc() (+0x260) [0xb6da8204]
(15) /usr/lib/icinga2/libbase.so: boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, icinga::WorkQueue>, boost::_bi::list1<boost::_bi::valueicinga::WorkQueue* > > >::run() (+0x24) [0xb6da8fc4]
(16) /lib/libboost_thread.so.1.54.0: (+0x9a08) [0xb6f53a08]
(17) /lib/libpthread.so.0: (+0x6d9c) [0xb6776d9c]

[icinga::ContextTrace*] =
(0) Reconnecting to PostgreSQL IDO database 'ido-pgsql'

[icinga::errinfo_message_*] = ERROR: duplicate key value violates unique constraint "uq_servicedependencies"
DETAIL: Key (instance_id, config_type, service_object_id, dependent_service_object_id, dependency_type, inherits_parent, fail_on_ok, fail_on_warning, fail_on_unknown, fail_on_critical)=(1, 0, 102, 96, 0, 0, 0, 0, 0, 0) already exists.

[icinga::errinfo_database_query_*] = INSERT INTO icinga_servicedependencies (dependent_service_object_id, instance_id, service_object_id) VALUES (96, 1, 102)

I guess this has to be something to do with service dependencies, so I'm not sure if this has something to do with the hostgroups problem. I'll try to find out where this error message comes from nevertheless. Just wanted to tell you about this now, maybe it is somehow related.

[icinga-migration]

Updated by gvegidy on 2014-02-15 23:44:56 +00:00

I now have singled out the database errors, see Bug #5665.

I can't reproduce the hostgroup problem on a x86_64 system using exactly the same config as on the ARM system I'm seeing it on. Both systems are Fedora 20, rpms compiled on the respective system from your srpms.

So I'm currently not sure if this problem is related to the ARM architecture or if there is something else going on. I'll investigate further.

[icinga-migration]

Updated by gvegidy on 2014-02-16 15:15:41 +00:00

Ok, I think I got it:

the objects.cache file is written out before the host is added to the HostGroup-Object. I added some Log() calls to the accessor methods of the HostGroup object:

[2014-02-16 15:25:23 +0100] <Q #0xb6dfbb68 W #0xb6dfbc50> debug/icinga: hostgroup linux-servers read: 0 Members
Context:
(0) Writing objects.cache file

[...]
[2014-02-16 15:25:24 +0100] <WQ #1> debug/icinga: host localhost added to hostgroup linux-servers
[2014-02-16 15:25:24 +0100]

information/config: Activated all objects.
[2014-02-16 15:25:24 +0100] debug/icinga: In IcingaApplication::Main()

When looking at the code, Host::Start() (from where the Host is added to the HostGroup) is called from within the same queue as StatusDataWriter::Start(). This happens in ConfigItem::ActivateItems() where all DynamicObjects are initialized.

In StatusDataWriter::Start(), StatusDataWriter::UpdateObjectsCache (from where objects.cache is written) is not called directly, but enqueued for async callback.

So in the end there is no explicit initialization order in the code, but the order this is called depends on thread scheduling and maybe code locations in memory. And this is system and architecture specific, so that is why I can see this problem on my ARM machine and not on x86_64.

I think to truely fix this, you should make sure that StatusDataWriter::UpdateObjectsCache can not be called before all object initialization is completed. As I just started looking into icinga2 code today, I don't know what would be the best way to accomplish this. So sorry, no patch from me this time.

[icinga-migration]

Updated by mfriedrich on 2014-02-17 08:44:59 +00:00

• Category set to libicinga
• Status changed from Feedback to Assigned
• Assigned to set to mfriedrich
• Target Version set to 0.0.8

[icinga-migration]

Updated by mfriedrich on 2014-02-20 16:06:41 +00:00

• Assigned to changed from mfriedrich to gbeutner

[icinga-migration]

Updated by gbeutner on 2014-03-05 11:13:30 +00:00

Hi,

your analysis is pretty much spot on. Please see if the latest commit in the "next" branches fixes this.

• Gunnar

[icinga-migration]

Updated by gbeutner on 2014-03-05 11:13:34 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset 979d6cc.

[icinga-migration]

Updated by gvegidy on 2014-03-09 12:48:41 +00:00

I tested the patch and can confirm that the issue is fixed.

Thank you very much.