Configuration error after database mainteinance

We monitor the servers of a small organization using Icinga2. Most of the servers are FreeBSD, while there are some Linux (Debian). Icinga2 server run in a FreeBSD jail.
Icinga was working perfect until we change the configuration of the mysql server to another IP.

Since then we get this kind error whe we try to start icinga2

service icinga2 start
Performing sanity check of icinga2 configuration: [2019-08-26 20:08:39 +0000] information/cli: Icinga    application loader (version: r2.10.5-1)
[2019-08-26 20:08:39 +0000] information/cli: Loading configuration file(s).
[2019-08-26 20:08:39 +0000] critical/config: Error: Object 'FreeBSD-servers' of type 'HostGroup' re-defined: in /usr/local/etc/icinga2/conf.d/groups/groups.conf: 5:1-5:34; previous definition: in /usr/local/etc/icinga2/conf.d/groups.conf: 5:1-5:34
Location: in /usr/local/etc/icinga2/conf.d/groups/groups.conf: 5:1-5:34
/usr/local/etc/icinga2/conf.d/groups/groups.conf(3):  */
/usr/local/etc/icinga2/conf.d/groups/groups.conf(4): 
/usr/local/etc/icinga2/conf.d/groups/groups.conf(5): object HostGroup "FreeBSD-servers" {
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/etc/icinga2/conf.d/groups/groups.conf(6):   display_name = "FreeBSD Servers"
/usr/local/etc/icinga2/conf.d/groups/groups.conf(7): 

FAILED

If I comment out the line in the configuration file, then the error would go to the next line and so on. I think it has something to do with the mysql configuration change.

The configuration was update in /usr/local/etc/icinga2/features-enabled/ido-mysql.conf

object IdoMysqlConnection "ido-mysql" {
  user = "icinga2"
  password = "a very good password"
  host = "192.168.xx.xxx"
  database = "icinga2"
}

For icingaweb /usr/local/etc/icingaweb2/resources.ini:

[icingaweb_db]
type = "db"
db = "mysql"
host = "192.168.xx.xxx"
port = ""
dbname = "icingaweb2"
username = "icingaweb2"
password = "another password"
charset = ""
persistent = "0"
use_ssl = "0"

[icinga_ido]
type = "db"
db = "mysql"
host = "192.168.xx.xxx"
port = ""
dbname = "icinga2"
username = "icinga2"
password = "other password"
charset = ""
persistent = "0"
use_ssl = "0"

[icinga2_director]
type = "db"
db = "mysql"
host = "192.168.xx.xxx"
dbname = "icinga2_director"
username = "icinga2_director"
password = "other password"
persistent = "0"
use_ssl = "0"
charset = "utf8"

The credentials have been tested and worked correctly with the mysql command line client. Icinga web works well but the icinga2 service does not start and the servers are not monitor.

When I try to start the server, there are no logs in the /var/log/icinga2 log files.

I am new with Icinga2 and FreeBSD, but I do have experience with Linux. I have search in the web and have not find a solution. I am not sure what is the problem :(, sorry.

icinga2 --version output

icinga2 - The Icinga 2 network monitoring daemon (version: r2.10.5-1)

Copyright (c) 2012-2019 Icinga GmbH (https://icinga.com/)
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

System information:
  Platform: Unknown
  Platform version: Unknown
  Kernel: FreeBSD
  Kernel version: 11.2-RELEASE-p13
  Architecture: amd64

Build information:
  Compiler: Clang 6.0.0
  Build host: 112amd64-quarterly-job-12

Application information:

General paths:
  Config directory: /usr/local/etc/icinga2
  Data directory: /var/lib/icinga2
  Log directory: /var/log/icinga2
  Cache directory: /var/cache/icinga2
  Spool directory: /var/spool/icinga2
  Run directory: /var/run/icinga2

Old paths (deprecated):
  Installation root: /usr/local
  Sysconf directory: /usr/local/etc
  Run directory (base): /var/run
  Local state directory: /var

Internal paths:
  Package data directory: /usr/local/share/icinga2
  State path: /var/lib/icinga2/icinga2.state
  Modified attributes path: /var/lib/icinga2/modified-attributes.conf
  Objects path: /var/cache/icinga2/icinga2.debug
  Vars path: /var/cache/icinga2/icinga2.vars
  PID path: /var/run/icinga2/icinga2.pid

The error says you redifiened an object. It clearly says in which file. Remove the double configured object and everything should be fine

Hi,

can you please show a full output of icinga2 daemon -C and also the content of the groups.conf file?

Cheers,
Michael

I don’t see double configuration. I would post the groups.conf file below

Icinga 2 daemon -C

[2019-08-27 13:05:07 +0000] information/cli: Icinga application loader (version: r2.10.5-1)
[2019-08-27 13:05:07 +0000] information/cli: Loading configuration file(s).
[2019-08-27 13:05:07 +0000] critical/config: Error: Object 'FreeBSD-servers' of type 'HostGroup' re-defined: in /usr/local/etc/icinga2/conf.d/groups/groups.conf: 5:1-5:34; previous definition: in /usr/local/etc/icinga2/conf.d/groups.conf: 5:1-5:34
Location: in /usr/local/etc/icinga2/conf.d/groups/groups.conf: 5:1-5:34
/usr/local/etc/icinga2/conf.d/groups/groups.conf(3):  */
/usr/local/etc/icinga2/conf.d/groups/groups.conf(4): 
/usr/local/etc/icinga2/conf.d/groups/groups.conf(5): object HostGroup "FreeBSD-servers" {  
                                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/etc/icinga2/conf.d/groups/groups.conf(6):   display_name = "FreeBSD Servers"
/usr/local/etc/icinga2/conf.d/groups/groups.conf(7): 

groups.conf

/**

  • Host group examples.
    */

object HostGroup “FreeBSD-servers” {
display_name = “FreeBSD Servers”

assign where host.vars.os == “FreeBSD”
}

object HostGroup “windows-servers” {
display_name = “Windows Servers”

assign where host.vars.os == “Windows”
}

/**

  • Service group examples.
    */

object ServiceGroup “ping” {
display_name = “Ping Checks”

assign where match(“ping*”, service.name)
}

object ServiceGroup “http” {
display_name = “HTTP Checks”

assign where match(“http*”, service.check_command)
}

object ServiceGroup “disk” {
display_name = “Disk Checks”

assign where match(“disk*”, service.check_command)

Seems you’ve copied the example configuration from conf.d into a specific sub directory in groups, but left the upper file there. This generates duplicated objects.

Cheers,
Michael

1 Like

Your where right, it wasn’t the only file, luckly we had backups and could compare the file structure.

Thanks very much!