Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Icinga2 startup fails, if network stack is not fully loaded. #6758
Icinga2 startup fails, if network stack is not fully loaded.
Icinga2 can't determine the FQDN of the host, if the startup of the network stack tooks longer than usual (e.g. if you use a brdige and several network interfaces.
Icinga2 does a fallback or could only get the hostname, but not the domain of the host, and fails while loading the certs to startup.
hostname is "icinga-01"
certs are stored with fqdn naming scheme
full log of initialization ...
If you do a restart after system is fully started, everything works as expected and the service is started.
Fails sometimes, if initialization of network stack is slow
Steps to Reproduce (for bugs)
Not reproducible everytime, because sometimes it works, sometimes not.
Copyright (c) 2012-2018 Icinga Development Team (https://icinga.com/)
Old paths (deprecated):
openSUSE 13.1 (i586)
I think it has something to do with name resolution. If no entry is set in /etc/hosts, getaddrinfo fails without network. If a entry is set in /etc/host, FQDN is set, also without network.
I'll get also messages like these:
Just to ensure, @jschanz can you show the content of the systemd icinga2.service unit?
It should contain
Have a look for further details at https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Target "network" is reached after icinga2 start:
I can reproduce this now ... Please unplug the network cable and try to use the following /etc/hosts
So no adress resultion (local, dns, etc.) is possible. Icinga2 is unable to determine the FQDN with getaddrinfo and fails while looking up for the certs in /var/lib/icinga2/certs/ and won't start due to that.
I tried to reproduce on CentOS 7. On CentOS7 with NetworkManager.service and NetworkManager-wait-online.service enabled Icinga 2 is always started after networking. Enabling the old network.service and disabling NetworkManager.service and NetworkManager-wait-online.service gave me the same problem. Disabling network.service and only enabling NetworkManager.service also did not cause a problem. So it is totally depending on the network managing service.
With an additional