# Removing downtime not possible **URL:** \ **Category:** Icinga 2\ **Created:** [February 5, 2019, 5:25pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315 "2019-02-05T17:25:21Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![nicolaiB](https://community.icinga.com/user_avatar/community.icinga.com/nicolaib/32/1929_2.png) [@nicolaiB](https://community.icinga.com/u/nicolaiB)\ **Post date:** [February 5, 2019, 5:25pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/1 "2019-02-05T17:25:21Z")
Hi, I ran into a strange behaviour, when I accidentally created a wrong downtime for a host and and tried to remove the downtime afterwards. The creation of the downtime object was not successful (says the API): ```auto { "results": [ { "code": 500.0, "status": "Action execution failed: 'Error: Function call 'localtime_r' failed with error code 75, 'Value too large for defined data type'\n'." } ] } ``` Although I can see the downtime in Icinga Web 2: ![Screenshot%20from%202019-02-05%2018-17-34](https://community.icinga.com/uploads/default/original/1X/1945168e43b6c0ff7f65d121acae8c0fdacf6282.png) … but if I try to remove the Downtime, I get an error: ```auto icinga2: Can't send external Icinga command: 404 No objects found. ``` Even if I try to remove all downtimes for this host by API, the broken downtime is still there. Any ideas? Did I oversee something or is this a bug (which I should report)? **Environment** Icinga2 version: 2.10.2-1 OS: CentOS 7.6.1810 ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [February 5, 2019, 8:02pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/2 "2019-02-05T20:02:29Z")
I’ve seen a similar thing with [https://github.com/Icinga/icinga2/issues/6871](https://github.com/Icinga/icinga2/issues/6871) which seems to happen only when specific times are 0 or lower. What parameters are needed to reproduce the problem? ---
**Author:** ![nicolaiB](https://community.icinga.com/user_avatar/community.icinga.com/nicolaib/32/1929_2.png) [@nicolaiB](https://community.icinga.com/u/nicolaiB)\ **Post date:** [February 5, 2019, 8:05pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/3 "2019-02-05T20:05:52Z")
I used a value for `time_end` which was bigger than allowed (by datatype), thus the downtime has no end. I’d guess that the downtime only resist as zombie in the IDO. ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [February 5, 2019, 8:09pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/4 "2019-02-05T20:09:13Z")
Ok, so you’ve hit an overflow with localtime\_r which causes the core to fail. For some reason, the IDO creation event happens thus leaving this zombie entry behind. If you’re using an end\_time after 2038, MySQL tends to throw an error as well. ---
**Author:** ![nicolaiB](https://community.icinga.com/user_avatar/community.icinga.com/nicolaib/32/1929_2.png) [@nicolaiB](https://community.icinga.com/u/nicolaiB)\ **Post date:** [February 5, 2019, 9:09pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/5 "2019-02-05T21:09:48Z")
OK. Can I safely delete the downtime entry in the IDO or do I have to keep something else in mind? ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [February 5, 2019, 9:22pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/6 "2019-02-05T21:22:41Z")
`icinga_scheduleddowntime` and `icinga_downtimehistory` should do the trick. ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [February 7, 2019, 8:38am UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/7 "2019-02-07T08:38:07Z")
In terms of the problem itself, how should we fix this … putting in sanitizers directly in the API sounds the best, doesn’t it? Or should the caller receive an immediate error? Cheers, Michael ---
**Author:** ![nicolaiB](https://community.icinga.com/user_avatar/community.icinga.com/nicolaib/32/1929_2.png) [@nicolaiB](https://community.icinga.com/u/nicolaiB)\ **Post date:** [February 7, 2019, 8:41am UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/8 "2019-02-07T08:41:00Z")
The best would be imho to prevent creating such broken downtimes (check boundaries and datatypes), so the REST request would fail with a certain error message. Thanks, Nicolai ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [February 7, 2019, 8:54am UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/9 "2019-02-07T08:54:07Z")
Ok, then we’ll have a lot of fun between 32bit time\_t (year 2038) and 64bit time\_t (year 3000) when using INT\_MAX. [https://docs.microsoft.com/de-de/cpp/c-runtime-library/reference/localtime-localtime32-localtime64?view=vs-2017](https://docs.microsoft.com/de-de/cpp/c-runtime-library/reference/localtime-localtime32-localtime64?view=vs-2017) TL;DR - 32 bit systems should die. ---
**Author:** ![nicolaiB](https://community.icinga.com/user_avatar/community.icinga.com/nicolaib/32/1929_2.png) [@nicolaiB](https://community.icinga.com/u/nicolaiB)\ **Post date:** [February 7, 2019, 9:01am UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/10 "2019-02-07T09:01:50Z")
Don’t know much about C++, but isn’t there any kind of “exception” raised if the value is to great? Or is this too late in context? ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [February 7, 2019, 3:00pm UTC](https://community.icinga.com/t/removing-downtime-not-possible/315/11 "2019-02-07T15:00:22Z")
The scope where the exception is thrown is different … actually I am thinking that the Log() call with FormatDateTime() triggers this in AddDowntime(). I haven’t yet had the change to reproduce this error with lldb attached.