jbreams/nagmq

Nag.py: Scheduled downtime with specific dates results in inaccurate downtime window

Closed this issue · 3 comments

bnh1 commented

Hi Jonathan,

When one tries to schedule downtime using nag.py with specific start and end times, the actual downtime is scheduled for the wrong period.

E.g.:

$ nag.py -s "02-18 07:05" -d 1 add downtime check_win_memory_phsical@myhost [check_win_memory_phsical@myhost]: Adding downtime for 0:01:00

The resultant downtime comment in Nagios appears as:

"This service has been scheduled for fixed downtime from 03-26-2036 14:33:16 to 03-26-2036 14:34:16. Notifications for the service will not be sent out during that time period."

This appears to be caused by time.strptime having a default year of 1900 when the year is not specified.

Setting starttime and endtime formats with %y- results in a correctly scheduled downtime window. E.g.:

$ diff nag.dbg.py /opt/nagmq-1.3/bin/nag.py 
225,226c225
<       starttime = datetime.strptime(opts.starttime, '%y-%m-%d %H:%M')
<       print (starttime)

---
>       starttime = datetime.strptime(opts.starttime, '%m-%d %H:%M')
247c246
<       endtime = datetime.strptime(opts.endtime, '%y-%m-%d %H:%M')

---
>       endtime = datetime.strptime(opts.endtime, '%m-%d %H:%M')
249c248
<   

---
> 
$ ./nag.dbg.py -s "14-02-18 07:14" -d 1 add downtime check_win_memory_phsical@myhost
2014-02-18 07:14:00
[check_win_memory_phsical@myhost]: Adding downtime for 0:01:00

The downtime comment in Nagios appears as:

"This service has been scheduled for fixed downtime from 02-18-2014 07:14:00 to 02-18-2014 07:15:00. Notifications for the service will not be sent out during that time period."

Hope things are going well,
ben

jbreams commented

Can you open a pull request for this?

bnh1 commented

Well, I can try. You should have it by now if I did it correctly.

Thanks,
ben

On Wed, Feb 19, 2014 at 5:53 PM, Jonathan Reams notifications@github.comwrote:

Can you open a pull request for this?

Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-35520399
.

Benjamin Hall
Lead Systems Engineer, CUIT
Columbia University
bnh1@columbia.edu

jbreams commented

Resolved in pull request 21.