In case the picture isn’t readable: It complains an error in file “[stage]/zones.d/dev_master/scheduled_downtimes.conf”.
The landscape consists of 2 Icinga servers. The mentioned file cannot be found on the satellite at all, but on the master in the stage directory. It does not exist in /etc/icinga*. So I stopped both Icinga instances, removed /var/lib/icinga2/api/* and restarted both instances. A “icinga2 daemon -C” doesn’t show any errors, but whenever I try to deploy the config, the file is regenerated in a new stage folder and the deployment fails again.
So I expected this configuration to exist inside the director only, but the only thing I could find there is:
But there is none:
So where can I find that file/configuration, so I can delete it? Or in other words, where is the source, those stage file is build from each time I run a deployment?
Thanks a lot.
Regards,
Dirk
Give as much information as you can, e.g.
Director version (System - About): 1.7.2
Icinga Web 2 version and modules (System - About): 2.7.3
Hi,
in the meantime I redeployed the last good config, but the action implementing the failed downtime definition is still in the activity queue and will cause the next deployment to fail again. Would be helpful, if I could remove that activity from the activity queue / stage.
After successful deployment of last good config, the kickstart wizard isn’t working anymore:
Hi,
I can see the downtime entry causing the problem in table “icinga_scheduled_downtime”. Can I delete the entry from that table safely, or will this destroy any dependencies inside the database?
I’d also like to know, why the director is showing me that there is an entry, but it doesn’t show me the entry itself, so I can’t delete it the correct way.
BTW: If I click on the task which created the downtime inside the activity log (which should lead me to the object), it shows “Page not found”.
Hi,
after a colleague created 2 new host objects, I was able to reach the downtime definition by clicking the “create” entry in the activity log and using the link in the “Action” row. Here I could delete the faulty downtime definition and run a new deployment.
