Re: [Nagios-users] service checks could not be rescheduled properly.
Julian Grunnell | Unix Analyst, Infrastructure | TD Direct Investing
T: +44 (0) 113 346 2824 | M: +44 (0) 7889 352527
Andreas Ericsson a...@op5.se
16/03/2012 10:14
Please respond to
Nagios Users List nagios-users@lists.sourceforge.net
To
Nagios Users List nagios-users@lists.sourceforge.net
cc
julian_grunn...@tdwh.co.uk
Subject
Re: [Nagios-users] service checks could not be rescheduled properly.
On 03/15/2012 11:31 AM, julian_grunn...@tdwh.co.uk wrote:
Anyone ... thought I'd go back to this. Does anyone have any ideas why I
would get the following in the Nagios logs:
nagios-03-10-2012-00.log:[1331336760] Warning: Check of service 'DEAL
SERVER SERVICE TCP 4099' on host 'TDUKUBS01' could not be rescheduled
properly. Scheduling check for next week...
nagios-03-10-2012-00.log:[1331336760] Warning: Check of service 'DEAL
SERVER SERVICE TCP 4099' on host 'TDUKUBS02' could not be rescheduled
properly. Scheduling check for next week...
As mentioed below, I've checked the config multiple times, I run 1100+
service checks across 100+ hosts and just these two are causing a
problem
- they differ in that they have specific time periods defined - all
detailed below. I've checked the various reports that NTP is at fault
but
it made no difference at all.
define timeperiod{
timeperiod_name ubs4099hours
alias UBS 4099 Dealserver Monitoring Hours
monday 23:46-20:30
tuesday 23:46-20:30
wednesday 23:46-20:30
thursday 23:46-20:30
friday 23:46-20:30
}
This timeperiod isn't valid. FROM 23:46 TO 20:30 on the same date,
there is no time for any checks to be executed in.
00:00-20:30,23:46-00:00
should work better, unless you meant 20:30-23:46, but I guess you
wouldn't have screwed it up if that's what you intended.
hth
--
Thanks Andreas - well your right, changed my times as above and the
scheduling now works. tbh no idea why I thought it would work how I had it
just didn't occur to me.
So thanks again - happy now.
J.
---
Consider the environment: Please don't print this e-mail unless you really need
to.
Confidentiality: This email and its attachments are intended for the above
named only and may be confidential. If they have come to you in error you must
take no action based on them, nor must you copy or show them to anyone; please
reply to this email and highlight the error.
Viruses: Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure that they are actually
virus-free.
Brokerage services provided by TD Direct Investing (Europe) Limited (a
subsidiary of The Toronto-Dominion Bank). Authorised and regulated by the
Financial Services Authority (FSA registered number 141282), member of the
London Stock Exchange and the PLUS market. Incorporated in England and Wales
under registration number 2101863. Registered office: Exchange Court, Duncombe
Street, Leeds LS1 4AX. Banking services provided by TD Bank N.V. authorised and
regulated by De Nederlandsche Bank and the Financial Services Authority for UK
Business (FSA registered number 216791). Incorporated in the Netherlands and
registered as a branch in England and Wales under branch registration number
BR006780.
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] service checks could not be rescheduled properly.
On 03/15/2012 11:31 AM, julian_grunn...@tdwh.co.uk wrote:
Anyone ... thought I'd go back to this. Does anyone have any ideas why I
would get the following in the Nagios logs:
nagios-03-10-2012-00.log:[1331336760] Warning: Check of service 'DEAL
SERVER SERVICE TCP 4099' on host 'TDUKUBS01' could not be rescheduled
properly. Scheduling check for next week...
nagios-03-10-2012-00.log:[1331336760] Warning: Check of service 'DEAL
SERVER SERVICE TCP 4099' on host 'TDUKUBS02' could not be rescheduled
properly. Scheduling check for next week...
As mentioed below, I've checked the config multiple times, I run 1100+
service checks across 100+ hosts and just these two are causing a problem
- they differ in that they have specific time periods defined - all
detailed below. I've checked the various reports that NTP is at fault but
it made no difference at all.
define timeperiod{
timeperiod_name ubs4099hours
alias UBS 4099 Dealserver Monitoring Hours
monday 23:46-20:30
tuesday 23:46-20:30
wednesday 23:46-20:30
thursday 23:46-20:30
friday 23:46-20:30
}
This timeperiod isn't valid. FROM 23:46 TO 20:30 on the same date,
there is no time for any checks to be executed in.
00:00-20:30,23:46-00:00
should work better, unless you meant 20:30-23:46, but I guess you
wouldn't have screwed it up if that's what you intended.
hth
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] service checks could not be rescheduled properly.
Anyone ... thought I'd go back to this. Does anyone have any ideas why I
would get the following in the Nagios logs:
nagios-03-10-2012-00.log:[1331336760] Warning: Check of service 'DEAL
SERVER SERVICE TCP 4099' on host 'TDUKUBS01' could not be rescheduled
properly. Scheduling check for next week...
nagios-03-10-2012-00.log:[1331336760] Warning: Check of service 'DEAL
SERVER SERVICE TCP 4099' on host 'TDUKUBS02' could not be rescheduled
properly. Scheduling check for next week...
As mentioed below, I've checked the config multiple times, I run 1100+
service checks across 100+ hosts and just these two are causing a problem
- they differ in that they have specific time periods defined - all
detailed below. I've checked the various reports that NTP is at fault but
it made no difference at all.
And if I force a check, it works and then schedules to run again tonight
at 23:46 when I want the time period to begin:
Thanks - Julian.
Julian Grunnell | Unix Analyst, Infrastructure | TD Direct Investing
T: +44 (0) 113 346 2824 | M: +44 (0) 7889 352527
julian_grunn...@tdwh.co.uk
14/11/2011 14:49
Please respond to
Nagios Users List nagios-users@lists.sourceforge.net
To
nagios-users@lists.sourceforge.net
cc
Subject
Re: [Nagios-users] service checks could not be rescheduled properly.
Hi - thanks, should have said this is one of the first posts I read. Lots
of mentions of NTPD and it should be fixed / still doesn't work. And in my
case whether I enable NTPD or not makes no difference. My checks for
specific hosts are still getting rescheduled for next week. I run multiple
Nagios instances and its only affecting this one - and annoyingly these
checks are some of the most important but just happen to need to run at
specific times of the day.
Any other help / ideas would be appreciated.
Thanks - J.
Julian Grunnell | Unix Analyst, Infrastructure | TD Waterhouse
T: +44 (0) 113 346 2824 | M: +44 (0) 7889 352527
Brandon Phelps bphe...@gls.com
11/11/2011 16:03
Please respond to
Nagios Users List nagios-users@lists.sourceforge.net
To
nagios-users@lists.sourceforge.net
cc
Subject
Re: [Nagios-users] service checks could not be rescheduled properly.
Check out this bug report on the nagios.org bug tracker:
http://tracker.nagios.org/view.php?id=31
On 11/11/2011 10:39 AM, julian_grunn...@tdwh.co.uk wrote:
Hi - does anyone know the answer to the following errors I'm getting in
the nagios.log for a handful of hosts that have a specific timeperiod
for checks set.
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS02' could not be rescheduled properly.
Scheduling check for next week...
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS01' could not be rescheduled properly.
Scheduling check for next week...
Obviously this is causing major issues as checks are just not being
carried out as expected, the hosts / services are defined as follows:
define host{
use unix_host_template ; Name of host template to use
icon_image win40.jpg
host_name TDUKUBS01
address 192.168.75.84
alias TDUKUBS01 192.168.75.84
}
define service{
use ubs-service
hostgroup_name ubsdealservers
service_description DEAL SERVER SERVICE TCP 4099
check_command check_ubs!4099
check_period ubs4099hours
}
define service{
name ubs-service
is_volatile 0
max_check_attempts 5
normal_check_interval 1
notification_interval 5
retry_check_interval 1
contact_groups dtns-ooh
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized
(disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if
necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program
restarts
retain_nonstatus_information 1 ; Retain non-status information across
program restarts
is_volatile 0 ; The service is not volatile
register 0
}
define timeperiod{
timeperiod_name ubs4099hours
alias UBS 4099 Dealserver Monitoring Hours
monday 23:46-20:30
tuesday 23:46-20:30
wednesday 23:46-20:30
thursday 23:46-20:30
friday 23:46-20:30
}
It all looks ok to me, if I manually re-schedule the check above it will
run fine but when it comes to the check being carried out as defined by
the timeperiod above again it will not run and then get scheduled for
the following week.
Any help would be appreciated.
Thanks - Julian.
Julian Grunnell | Unix
Re: [Nagios-users] service checks could not be rescheduled properly.
Hi - thanks, should have said this is one of the first posts I read. Lots
of mentions of NTPD and it should be fixed / still doesn't work. And in my
case whether I enable NTPD or not makes no difference. My checks for
specific hosts are still getting rescheduled for next week. I run multiple
Nagios instances and its only affecting this one - and annoyingly these
checks are some of the most important but just happen to need to run at
specific times of the day.
Any other help / ideas would be appreciated.
Thanks - J.
Julian Grunnell | Unix Analyst, Infrastructure | TD Waterhouse
T: +44 (0) 113 346 2824 | M: +44 (0) 7889 352527
Brandon Phelps bphe...@gls.com
11/11/2011 16:03
Please respond to
Nagios Users List nagios-users@lists.sourceforge.net
To
nagios-users@lists.sourceforge.net
cc
Subject
Re: [Nagios-users] service checks could not be rescheduled properly.
Check out this bug report on the nagios.org bug tracker:
http://tracker.nagios.org/view.php?id=31
On 11/11/2011 10:39 AM, julian_grunn...@tdwh.co.uk wrote:
Hi - does anyone know the answer to the following errors I'm getting in
the nagios.log for a handful of hosts that have a specific timeperiod
for checks set.
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS02' could not be rescheduled properly.
Scheduling check for next week...
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS01' could not be rescheduled properly.
Scheduling check for next week...
Obviously this is causing major issues as checks are just not being
carried out as expected, the hosts / services are defined as follows:
define host{
use unix_host_template ; Name of host template to use
icon_image win40.jpg
host_name TDUKUBS01
address 192.168.75.84
alias TDUKUBS01 192.168.75.84
}
define service{
use ubs-service
hostgroup_name ubsdealservers
service_description DEAL SERVER SERVICE TCP 4099
check_command check_ubs!4099
check_period ubs4099hours
}
define service{
name ubs-service
is_volatile 0
max_check_attempts 5
normal_check_interval 1
notification_interval 5
retry_check_interval 1
contact_groups dtns-ooh
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized
(disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if
necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program
restarts
retain_nonstatus_information 1 ; Retain non-status information across
program restarts
is_volatile 0 ; The service is not volatile
register 0
}
define timeperiod{
timeperiod_name ubs4099hours
alias UBS 4099 Dealserver Monitoring Hours
monday 23:46-20:30
tuesday 23:46-20:30
wednesday 23:46-20:30
thursday 23:46-20:30
friday 23:46-20:30
}
It all looks ok to me, if I manually re-schedule the check above it will
run fine but when it comes to the check being carried out as defined by
the timeperiod above again it will not run and then get scheduled for
the following week.
Any help would be appreciated.
Thanks - Julian.
Julian Grunnell | Unix Analyst, Infrastructure | TD Waterhouse
T: +44 (0) 113 346 2824 | M: +44 (0) 7889 352527
Consider the environment. Please don't print this e-mail unless you
really need to.
Confidentiality: This email and its attachments are intended for the
above named only and may be confidential. If they have come to you in
error you must take no action based on them, nor must you copy or show
them to anyone; please reply to this email and highlight the error.
Viruses: Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure that they are actually
virus-free.
Brokerage services provided by TD Waterhouse Investor Services (Europe)
Limited (a subsidiary of The Toronto-Dominion Bank). Authorised and
regulated by the Financial Services Authority (FSA registered number
141282), member of the London Stock Exchange and the PLUS market.
Incorporated in England and Wales under registration number 2101863.
Registered office: Exchange Court, Duncombe Street, Leeds LS1 4AX.
Banking services provided by TD Waterhouse Bank N.V. authorised and
regulated by De Nederlandsche Bank and the Financial Services Authority
[Nagios-users] service checks could not be rescheduled properly.
Hi - does anyone know the answer to the following errors I'm getting in
the nagios.log for a handful of hosts that have a specific timeperiod for
checks set.
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS02' could not be rescheduled properly.
Scheduling check for next week...
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS01' could not be rescheduled properly.
Scheduling check for next week...
Obviously this is causing major issues as checks are just not being
carried out as expected, the hosts / services are defined as follows:
define host{
use unix_host_template ; Name of host
template to use
icon_image win40.jpg
host_name TDUKUBS01
address 192.168.75.84
alias TDUKUBS01 192.168.75.84
}
define service{
use ubs-service
hostgroup_name ubsdealservers
service_description DEAL SERVER SERVICE TCP 4099
check_command check_ubs!4099
check_periodubs4099hours
}
define service{
nameubs-service
is_volatile 0
max_check_attempts 5
normal_check_interval 1
notification_interval 5
retry_check_interval1
contact_groups dtns-ooh
active_checks_enabled 1 ; Active
service checks are enabled
passive_checks_enabled 1 ; Passive
service checks are enabled/accepted
parallelize_check 1 ; Active
service checks should be parallelized (disabling this can lead to major
performance problems)
obsess_over_service 1 ; We should
obsess over this service (if necessary)
check_freshness 0 ; Default is
to NOT check service 'freshness'
notifications_enabled 1 ; Service
notifications are enabled
event_handler_enabled 1 ; Service
event handler is enabled
flap_detection_enabled 1 ; Flap
detection is enabled
failure_prediction_enabled 1 ; Failure
prediction is enabled
process_perf_data 1 ; Process
performance data
retain_status_information 1 ; Retain
status information across program restarts
retain_nonstatus_information1 ; Retain
non-status information across program restarts
is_volatile 0 ; The service
is not volatile
register0
}
define timeperiod{
timeperiod_name ubs4099hours
alias UBS 4099 Dealserver Monitoring Hours
monday 23:46-20:30
tuesday 23:46-20:30
wednesday 23:46-20:30
thursday23:46-20:30
friday 23:46-20:30
}
It all looks ok to me, if I manually re-schedule the check above it will
run fine but when it comes to the check being carried out as defined by
the timeperiod above again it will not run and then get scheduled for the
following week.
Any help would be appreciated.
Thanks - Julian.
Julian Grunnell | Unix Analyst, Infrastructure | TD Waterhouse
T: +44 (0) 113 346 2824 | M: +44 (0) 7889 352527
___
Consider the environment: Please don't print this e-mail unless you really need
to.
Confidentiality: This email and its attachments are intended for the above
named only and may be confidential. If they have come to you in error you must
take no action based on them, nor must you copy or show them to anyone; please
reply to this email and highlight the error.
Viruses: Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure that they are actually
virus-free.
Brokerage services provided by TD Waterhouse Investor Services (Europe) Limited
(a subsidiary of The Toronto-Dominion Bank). Authorised and regulated by the
Financial Services Authority (FSA registered number 141282), member of the
London Stock Exchange and the PLUS market. Incorporated in England and Wales
under registration number 2101863. Registered office: Exchange Court, Duncombe
Street, Leeds LS1 4AX. Banking services provided by TD Waterhouse Bank N.V.
authorised and regulated by De Nederlandsche Bank and the Financial Services
Authority for UK Business (FSA registered number 216791). Incorporated in the
Netherlands and registered as a branch in
Re: [Nagios-users] service checks could not be rescheduled properly.
Check out this bug report on the nagios.org bug tracker:
http://tracker.nagios.org/view.php?id=31
On 11/11/2011 10:39 AM, julian_grunn...@tdwh.co.uk wrote:
Hi - does anyone know the answer to the following errors I'm getting in
the nagios.log for a handful of hosts that have a specific timeperiod
for checks set.
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS02' could not be rescheduled properly.
Scheduling check for next week...
[Wed Nov 9 23:46:00 2011] Warning: Check of service 'DEAL SERVER SERVICE
TCP 4099' on host 'TDUKUBS01' could not be rescheduled properly.
Scheduling check for next week...
Obviously this is causing major issues as checks are just not being
carried out as expected, the hosts / services are defined as follows:
define host{
use unix_host_template ; Name of host template to use
icon_image win40.jpg
host_name TDUKUBS01
address 192.168.75.84
alias TDUKUBS01 192.168.75.84
}
define service{
use ubs-service
hostgroup_name ubsdealservers
service_description DEAL SERVER SERVICE TCP 4099
check_command check_ubs!4099
check_period ubs4099hours
}
define service{
name ubs-service
is_volatile 0
max_check_attempts 5
normal_check_interval 1
notification_interval 5
retry_check_interval 1
contact_groups dtns-ooh
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized
(disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program
restarts
retain_nonstatus_information 1 ; Retain non-status information across
program restarts
is_volatile 0 ; The service is not volatile
register 0
}
define timeperiod{
timeperiod_name ubs4099hours
alias UBS 4099 Dealserver Monitoring Hours
monday 23:46-20:30
tuesday 23:46-20:30
wednesday 23:46-20:30
thursday 23:46-20:30
friday 23:46-20:30
}
It all looks ok to me, if I manually re-schedule the check above it will
run fine but when it comes to the check being carried out as defined by
the timeperiod above again it will not run and then get scheduled for
the following week.
Any help would be appreciated.
Thanks - Julian.
Julian Grunnell | Unix Analyst, Infrastructure | TD Waterhouse
T: +44 (0) 113 346 2824 | M: +44 (0) 7889 352527
Consider the environment. Please don't print this e-mail unless you
really need to.
Confidentiality: This email and its attachments are intended for the
above named only and may be confidential. If they have come to you in
error you must take no action based on them, nor must you copy or show
them to anyone; please reply to this email and highlight the error.
Viruses: Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure that they are actually
virus-free.
Brokerage services provided by TD Waterhouse Investor Services (Europe)
Limited (a subsidiary of The Toronto-Dominion Bank). Authorised and
regulated by the Financial Services Authority (FSA registered number
141282), member of the London Stock Exchange and the PLUS market.
Incorporated in England and Wales under registration number 2101863.
Registered office: Exchange Court, Duncombe Street, Leeds LS1 4AX.
Banking services provided by TD Waterhouse Bank N.V. authorised and
regulated by De Nederlandsche Bank and the Financial Services Authority
for UK Business (FSA registered number 216791). Incorporated in the
Netherlands and registered as a branch in England and Wales under branch
registration number BR006780.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
--
RSA(R) Conference 2012
Save $700 by Nov 18
