Removing downtime not possible

Icinga 2
1

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):

{                                                                                                                                                                                       
    "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
Screenshot from 2019-02-05 18-17-34.png1720Ă—635 79.5 KB

… but if I try to remove the Downtime, I get an error:

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

2

I’ve seen a similar thing with 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?

3

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.

4

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.

1 Like
5

OK. Can I safely delete the downtime entry in the IDO or do I have to keep something else in mind?

6

icinga_scheduleddowntime and icinga_downtimehistory should do the trick.

7

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

8

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

9

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

TL;DR - 32 bit systems should die.

1 Like
10

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?

11

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.