CMK version:
2.0.0p27 & 2.1.0p9
OS version:
All
Error message:
"Cannot lookup IP address of ‘HOSTNAME’ …
With 2.0 and 2.1 the processing of shadow host files is broken as the system tries to lookup all IP’s of these shadow hosts. IP is already there inside the shadow host config file.
It looks like the code inside “lib/python3/cmk/base/core_config.py” → function “ip_address_of” is broken as this function knows nothing about the host, if it is a real or shadow host.
Hi Andreas.
I can confirm this problem. I have exactly the same problem by using the cmcdump mechanism, when I activate changes. Looks like that actication ignores the shadow data.
Regards,
Christian
Hi Andreas and Christian,
I’ve forwarded this issue to the developers.
Thank you for reporting it! I’ll post it here when there is an update, if that is ok.
Hi guys
Can I take a look at your hosts.mk and output of cmcdump?
Best regards,
Sergey Kipnis
Here you find my cmcdump, config and hosts.mk. There is also a problem with the state notification. See BUG: No notification when state changes in cmcdump - Troubleshooting - Checkmk Community
Best regards,
Christian
hosts.mk.txt (5,8 KB)
montp4.mk.txt (56,5 KB)
montp4.state.txt (55,1 KB)
Thank you, Christian. The error has been confirmed and could be reproduced.
Sergey
Hi Sergej.
Thanks for that. Please look also at the other point. It’s also important that this work.
Best regards,
Christian
I will redirect state problem to other person.
Just for my understanding, your hosts have no configured IP address? and marked as a no-ip?
Correct?
Best regards,
Sergey
Here a very small example. One host on the remote site
Name: example
IP: 172.24.255.29
Config Dump - faraway.mk
# Created by /omd/sites/faraway/bin/cmcdump -C
shadow_hosts.update({'example': {'alias': 'example', 'address': '172.24.255.29', 'parents': [], 'check_command': 'check-mk-host-smart', 'check_command_expanded': 'check-mk-host-smart!', 'check_period': '24X7', 'check_interval': 0.1, 'contact_groups': ['all'], 'custom_variables': {'TAGS': '/wato/ auto-piggyback ip-v4 ip-v4-only lan no-agent no-snmp ping prod site:faraway', 'ADDRESS_6': '', 'ADDRESSES_6': '', 'ADDRESS_4': '172.24.255.29', 'ADDRESS_FAMILY': '4', 'ADDRESSES_4': '', 'FILENAME': '/wato/hosts.mk'}, 'first_notification_delay': 0, 'flap_detection_enabled': 1, 'groups': ['check_mk'], 'max_check_attempts': 1, 'notification_interval': 0, 'notification_period': '24X7', 'notifications_enabled': 1, 'process_performance_data': 0, 'retry_interval': 0.1, 'service_period': '24X7', 'services': [{'description': 'PING', 'check_command': 'check-mk-ping!-w 200.00,80.00% -c 500.00,100.00% 172.24.255.29', 'check_command_expanded': 'check-mk-ping!-w 200.00,80.00% -c 500.00,100.00% 172.24.255.29', 'check_period': '24X7', 'check_interval': 1, 'contact_groups': ['all'], 'custom_variables': {}, 'first_notification_delay': 0, 'flap_detection_enabled': 1, 'groups': [], 'max_check_attempts': 1, 'notification_interval': 0, 'notification_period': '24X7', 'notifications_enabled': 1, 'process_performance_data': 1, 'retry_interval': 1, 'service_period': '24X7'}]}})
After copy to the central site a “cmk --debug -vvR” produce the following output.
Trying to acquire lock on /omd/sites/central/etc/check_mk/main.mk
Got lock on /omd/sites/central/etc/check_mk/main.mk
Generating configuration for core (type cmc)...
Trying to acquire lock on /omd/sites/central/var/check_mk/core/helper_config/serial.mk
Got lock on /omd/sites/central/var/check_mk/core/helper_config/serial.mk
Releasing lock on /omd/sites/central/var/check_mk/core/helper_config/serial.mk
Released lock on /omd/sites/central/var/check_mk/core/helper_config/serial.mk
time period '24X7': 2 time points
Starting full compilation for all hosts Creating global helper config...OK
Creating cmc protobuf configuration...
WARNING: Cannot lookup IP address of 'example' (Failed to lookup IPv4 address of example via DNS: [Errno -3] Temporary failure in name resolution). The host will not be monitored correctly.
Trying to acquire lock on /omd/sites/central/var/check_mk/core/helper_config/2/core_host_config/example
Got lock on /omd/sites/central/var/check_mk/core/helper_config/2/core_host_config/example
Releasing lock on /omd/sites/central/var/check_mk/core/helper_config/2/core_host_config/example
Released lock on /omd/sites/central/var/check_mk/core/helper_config/2/core_host_config/example
Trying to acquire lock on /omd/sites/central/var/check_mk/core/helper_config/2/helper_cache_info
Got lock on /omd/sites/central/var/check_mk/core/helper_config/2/helper_cache_info
Releasing lock on /omd/sites/central/var/check_mk/core/helper_config/2/helper_cache_info
Released lock on /omd/sites/central/var/check_mk/core/helper_config/2/helper_cache_info
OK
/omd/sites/central/var/nagios/retention.dat not found, not importing Nagios state./omd/sites/central/var/check_mk newer than /omd/sites/central/var/nagios/retention.dat, not importing Nagios state./omd/sites/central/var/check_mk/core/config.pb written.
Restarting monitoring core...OK
Releasing lock on /omd/sites/central/etc/check_mk/main.mk
Released lock on /omd/sites/central/etc/check_mk/main.mk
On this central site was no host existing an nothing configured. The site was completely new created.
The single host itself is correctly shown as a shadow host inside the central site. But the IP lookup takes a huge amount of time in bigger production systems.
@ChristianM do you mean the notification thing as “the other point”?
In case you do: there never were notifications for shadow objects and these never were intended. Shadow objects exist for viewing purposes only - just like documented… 
Hi Marcel.
This is not well documentet. In the Documentation you find this:
Since brief state changes – depending on the periodic interval selected on the central site – may not be visible, a notification through the central site is not ideal. If however the central site is utilized as a purely display site – as a central overview of all customers for example – this method definitely has its advantages.
You need to have the notificatein, when you like to have the problems in your ticket systems, also from dumped sites.
The fix is in review now.
the Bug is still present in 2.0p33, will it be fixed?
I can only say that in 2.1 it is fixed.
yes thats true i’ve tested it also with version 2.1. , but at this time i must use version 2.0, and there the Bug is still present.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.