Mantis - ISSUES

0000447: Nagios 3.5.0 problem with german Umlaut in Status Information

We made an update from Nagios 3.3.1 to Nagios 3.5.0. After this update the displayed result (Status Information) of the CheckEventLog is distorted, if it contains german umlauts like äöüÄÖÜ. When the "Status Information" is complete empty, all further events are not displayed.

0000455: Nagios go down every night when (maybe) logrotate

Nagios go down every night when (maybe) logrotate

0000392: having per service check timeout would be useful

service_check_timeout is a global variable and applies to all checks.

It would be good to have capability to define timeout for each service.

In our system we have some very long running checks but we do not want to increase the service_check_timeout value as it impacts all other checks that should be finished within that period. We just want to run some checks longer than others.

0000454: Vertical bar/pipe (|) character in plugin output

It's possible for a plugin to have a vertical bar (|) character in its regular output. For example, I've seen cases where check_logfiles does this when there is a '|' in /var/log/messages. Nagios interprets anything after the '|' as performance data, so all of the plugin output doesn't get reported and performance data for that point in time is corrupt.

A solution would be for Nagios to support a way to escape the '|' in plugin output. If it did, the author of any such plugin could escape any '|' characters in the regular output.

'\' would be an obvious choice for an escape character.

0000453: There is no Macro to retrieve addresses of hostgroup members

$HOSTGROUPMEMBERS$ will retrieve the names of hosts in a hostgroup, but not the addresses. A $HOSTGROUPMEMBERSADDRESSES$ macro would be very useful. If I want to feed this info into a service check or host check, I currently have to feed $HOSTGROUPMEMBERS$ into an external script that will parse the nagios configs to find the addresses.

0000452: additional service check intervals...

i too would like to add my vote in favor of below report.... i have numerous service checks whose intervals are 1x hourly or 1x daily, but if it goes to WARN or CRIT, i would like to have an interval setting for those hard states so to check more often (every few minutes) until the state returns to OK thus back to 1x hourly/daily.....

http://tracker.nagios.org/view.php?id=318 [^]

0000318: add a feature to set a different checking interval in hard error states (not OK/UP or soft error states)

Hi.

From my own readings and what I was told, the following is not yet possible but sounds quite useful to me:

Currently one can set to check intervals:
check_interval: during ALL (both OK/UP and error) HARD states
retry_interval: during SOFT error states

I'd like to have another one added (probably with a better name, though):
check_interval_error which defaults to check_interval (to retain compatibility.

check_interval: should then only be used for OK/UP HARD states (no longer for error states).
check_interval_error: shall be used for any non-OK/HARD states

IMHO, nothing would need to be changed for retry_interval, as there are no SOFT OK/UP states, right?

Rationale/Motivation:
Right now, the following scenario cannot be handled:
- There are services, which need to be checked only very rarely (perhaps not even daily), e.g. whether SSH is running (or whether a backup cron job is in place).
These things typically fail/crash never but if they do (or if they are missing like the script) one want's to no it so it can be fixed and works when it's really needed then.

- There are services, which should in principle never fail just temporarily (and therefore using max_check_attempts > 1 and SOFT states may not be the most perfect solution).
Same example, SSH... it either fails always because it crashed or of missing permissions (iptables, etc.) or it should work.
I say should, because practise shows that sometimes ssh checks fail temporarily. But usually this is not a problem with SSH itself then, but something else... e.g. some deeply hidden network issue.

So what I in principle want is:
Do some checks very rarely, but get a hard state (and therby notifications) immediately (thus max_check_attempts = 1).
That works so far, but the problem now is,... one already has a hard state now and the check happens only very rarely... so if one doesn't manually re-schedule one, it takes the long time (e.g. a day or so) till nagios realises that everything is already ok again.

Introducing the option I've proposed above would allow this (and also several use cases I could think of).

Obviously the names of the options would then be somewhat misleading and better would be a complete renaming e.g.
check_interval_hard_ok (= current check_interval)
check_interval_hard_error (what I propose here)
check_interval_soft_error (= current retry_interval)

Looking forward to hear you thoughts :)

Chris.

0000444: Nagios 3.5.0 problem with macro $ADMINEMAIL$ : @ is converted to %40 after 2 nagios reload

Hello,

I encountered a bug on nagios 3.5.0 that I did not have on nagios 3.4.1.
I explained this bug here :
http://support.nagios.com/forum/viewtopic.php?f=7&t=10144&p=51314#p51314 [^]

and here (for french speaker) :
http://forums.monitoring-fr.org/index.php?topic=6612.0 [^]

Here is the description of the bug :

The problem occurs after a second reload of Nagios.

Here is the notification command :

define command{
command_name notification_service_par_mail
command_line $USER1$/sendmailservices.sh "$CONTACTEMAIL$" "$ADMINEMAIL$"
}

Here is my notification script (for test) :

#!/bin/bash

TO=$1
EMETTEUR=$2

echo "$TO $EMETTEUR" >> /tmp/notifBash.log

1- I restart Nagios and force a notification, everything works fine :

tail /tmp/notifBash.log
contact@domain.fr user@domain.fr

2- I reload Nagios and force a notification, everything works fine :

tail /tmp/notifBash.log
contact@domain.fr user@domain.fr

3- I reload Nagios again and force a notification, problem occurs :

tail /tmp/notifBash.log
contact@domain.fr user%40domain.fr

--- Another test, if my script sendmailservices.sh is not executable :

1- I restart Nagios and force a notification, here is the nagios warning :

[1366287128] Warning: Attempting to execute the command "/usr/local/nagios/libexec/sendmailservices.sh "contact@domain.fr" "user@domain.fr"" resulted in a return code of 126. Make sure the script or binary you are trying to execute actually exists...

2- I reload Nagios and force a notification, here is the nagios warning :

[1366287189] Warning: Attempting to execute the command "/usr/local/nagios/libexec/sendmailservices.sh "contact@domain.fr" "user@domain.fr"" resulted in a return code of 126. Make sure the script or binary you are trying to execute actually exists...

3- I reload Nagios again and force a notification, here is the nagios warning :

[1366287254] Warning: Attempting to execute the command "/usr/local/nagios/libexec/sendmailservices.sh "contact@domain.fr" "user%40domain.fr"" resulted in a return code of 126. Make sure the script or binary you are trying to execute actually exists...

My conclusion : after a second reload, nagios converts the '@' in the 'ADMINEMAIL' macro...

0000407: Reloading nagios config causes spaces in notifications to become plus signs

If Nagios is issued a reload command through the var/rw/nagios.cmd interface, it appears to have some weird bug where processing macros changes spaces to plus signs. The even stranger thing is that it starts out doing it with the $HOSTDURATION$ macro first. If you let it continue within about a day or so it starts to do the same for $HOSTALIAS$. An example is if $HOSTDURATION$ is "0d 0h 2m 29s" it will change it to be "0d+0h+2m+29s". If you stop the Nagios daemon completely and then start it, the issue goes away. I can trigger it every time by issuing a reload. Service notifications/macros seem to be unaffected.

0000263: triggered downtimes for child hosts will be deleted on nagios service restart

Hi,

Please find below the steps to reproduce this issue on Nagios v3.2.1 and v3.3.1, compiled from original sources, without any additional patches applied:

0000001 set up scheduled triggered downtime for child hosts
Current Status > Hosts
- select localhost
- Schedule downtime for this host
. put in comment
. use standard type fixed
. Schedule triggered downtime for all child hosts

System > Downtime
- shows downtime for both hosts: localhost, ntvm

Current Status > Hosts
- shows downtime icons on both hosts: localhost, ntvm

=> stop nagios process
=> check retention.dat, contains both host downtimes
=> save retention.dat into retention.dat_1 (see attachment)
=> start nagios process

0000002 check for downtimes set up in step 0000001
System > Downtime
- shows downtime for localhost only

Current Status > Hosts
- shows downtime icons on both hosts: localhost, ntvm

=> stop nagios process
=> check retention.dat, contains both host downtimes
=> save retention.dat into retention.dat_2 (see attachment)
=> start nagios process

0000003 check for downtimes set up in step 0000001
System > Downtime
- shows downtime for localhost only

Current Status > Hosts
- shows downtime icons on localhost only

=> stop nagios process
=> check retention.dat, contains host downtime for localhost only
=> save retention.dat into retention.dat_3 (see attachment)

You will find a small test configuration and the 3 retention.dat files attached.

Best regards

Michael

0000445: Adding triggered downtime for child hosts causes a SIGSEGV on restart/reload

I upgraded Nagios from v3.2.1 to v.3.5.0 on Saturday evening (20/4/13). It was running fine until I restarted it yesterday evening. The restart failed with the following error on the last line of nagios.log:

Caught SIGSEGV, shutting down...

It would not restart again without the above error. I narrowed it down to a problem with retention.dat as clearing this down and restarting solved the problem. It worked fine for a while then hit the same problem.

After some more troubleshooting, I noticed that scheduling triggered downtime for a host was causing the problem. On a restart, the last entry in nagios.log before the SIGSEGV was the parent host that the triggered hosts were dependant on. It works fine if I schedule downtime without triggering downtime for child hosts.

I can reproduce this every time.

I'm also seeing an issue similar to the bug reported in 0000263. When using the retention.dat from my last backup before upgrade, there is no downtime scheduled for any of the child hosts, only the parents despite the child hosts being listed in retention.dat with triggered_by set to the downtime_id of the parent.

If you need any more information, let me know.

regards,
Aidan

0000448: Nagios skips Next Scheduled Check for some tests

Every few weeks, Nagios will not run a test for some services on its 'Next Scheduled Check' time. It then has it set in the past and never runs until Nagios is restarted and the above field gets a new future time.

0000443: Broken check scheduling with exclusions in format YYYY-MM-DD

I used the "2013-04-15" format in the exclusions, and I observed an "erratic" behavior, in terms of check scheduling. I am using Nagios Core 3.4.1. I would expect next check for "Current Load" to be scheduled for 2013-04-16 07:00:00. Instead, it's scheduled for 04-23-2013 00:00:00.

===============================================================================
define service {
host_name localhost
service_description Current Load
use local-service
check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0!!!!!!
check_period test_timeperiod
register 1
}
===============================================================================
define timeperiod {
timeperiod_name test_timeperiod
alias test_timeperiod
exclude test_exclusions
sunday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
saturday 00:00-24:00
friday 00:00-24:00
monday 00:00-24:00
}
===============================================================================
define timeperiod {
timeperiod_name test_exclusions
alias test_exclusions
2013-04-18 07:00-24:00
2013-04-17 17:00-24:00
2013-04-16 00:00-07:00
2013-04-19 00:00-24:00
2013-04-15 15:15-24:00
}
===============================================================================

0000442: service_check_timeout_state missing in documentation

In the changelog for 3.4.0 there is a new configuration option called "service_check_timeout_state". However it isn't documented anywhere!

Only detailed information on how to configure this I found on the nagios-devel mailing list: http://marc.info/?l=nagios-devel&m=126574074724009&w=2 [^]

This needs to be added to: http://nagios.sourceforge.net/docs/nagioscore/3/en/objectdefinitions.html#service [^]

0000440: force_notification cannot be automatically checked

When you manually type the link that loads the "Send custom service notification" page and you want to have the Force or Broadcast checkboxes already selected, there is no change, the checkboxes are not selected.

The address I type is something like this:

http://aaa.bbb.ccc.ddd/nagios/cgi-bin/cmd.cgi?cmd_typ=160&host=HOST1&service=SERVICE1&force_notification [^]

Similar for Broadcast:

http://aaa.bbb.ccc.ddd/nagios/cgi-bin/cmd.cgi?cmd_typ=160&host=HOST1&service=SERVICE1&broadcast_notification [^]

0000364: RPM SPEC file calls configure with --datarootdir instead of --datadir - build fails

Hi,

The RPM SPEC file included in 3.4.1 calls configure with the --datarootdir parameter, but this is unrecognised. configure --help suggests that datadir is correct.

0000439: Hide Hosts in Group which have "No matching services"

Users see every host in hostgroups and servicegroups, where own hosts or services are located.

Hosts which are not assigned to user will display "No matching services" in the overview.

Can you fix this and hide all hosts, which have "No matching services", because they are not assigned to user ??

0000438: Reloads during downtime causes wrong availability calculations

In cgi/avail.c there is a function ,,compute_subject_downtime'' which increases variable service_downtime_depth (or host_downtime_depth) after every ,,DOWNTIME ALERT;STARTED'' during searching of nagios archive logs (function scan_log_file_for_archived_state_data). This is ok, because you can have two or more downtimes overlaping each other and *_downtime_depth variables are decreased after finding the end of downtime. But there is an issue:

Function scan_log_file_for_archived_state_data doesn't connect downtime starts and stops, so if you have one real downtime, but there will be two or more lines for this one particular service (or host) that say the service has entered a scheduled downtime and only one that ends the downtime, so next critical and warning alerts will be counted as scheduled.

Multiplication of lines with information that service (host) entering downtime occurs when during downtime you reload/restart nagios (ex. after changing configuration). This is done in handle_scheduled_downtime function in common/downtime.c. So maybe there should be information about downtime id in logs so avail.c could increase downtime's depth only for new downtimes.

I've tested it on Nagios 3.2.3, but found that main algorithm didn't change also in 3.5.0.

0000437: Typo/Error in notification_interval for host and service escalations

From: http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html [^]

For every notification_interval description, the following text is used:
notification_interval: This directive is used to determine the interval at which notifications should be made while this escalation is valid. If you specify a value of 0 for the interval, Nagios will send the first notification when this escalation definition is valid, but will then prevent any more problem notifications from being sent out for the host. Notifications are sent out again until the host recovers. . .

The problem sentence:
Notifications are sent out again until the host recovers.

Should probably read:
Notifications are not sent out again until the host recovers.

Or:
Notifications are sent out again once the host recovers.

0000436: Current Load

I have
2013-04-01 04:44:35] SERVICE ALERT: nms.sov11;Current Load;WARNING;HARD;4;WARNING - load average: 1.74, 3.04, 3.83
for my servers but i don't understand why ?
Every day after 3:00 night nagios start send this notifications .
I don't now what process start exactly in that time.

0000375: Freshness expiration never reached

There is a possibility that a freshness expiration is never reached for a host/service if Nagios is restarted frequently.

Here is the offending code in base/checks.c

if (temp_service->check_type == SERVICE_CHECK_PASSIVE) {
if (temp_service->last_check < event_start &&
event_start - last_program_stop < freshness_threshold * 0.618)
{
expiration_time = event_start + freshness_threshold;
}
}

An example situation is you create a passive only service with a 48 hour freshness threshold. Nagios needs to run continuously for 29.664 hours before it will stop resetting the freshness expiration.

0000412: Rotated log files should use YYYY-MM-DD for date in filenames

The rotated log files created by Nagios use filenames that do not sort naturally when getting a directory listing. This is because the filenames look like "nagios-MM-DD-YYYY-00.log"

It would help greatly if the filenames used YYYY-MM-DD for the date so they would sort in temporal order when getting a directory listing.

0000294: Service notifications sent while service is in scheduled downtime

Given the following scenario...

Service A Critical hard state reached and corresponding notification sent.
Downtime scheduled for Service A's host until well beyond when the recovery will occur.
Service A Recovery hard state (Ok) reached and corresponding notification sent.

The next test I did was to verify that I didn't need to schedule downtime for the host as well, so I repeated the above scenario except that I scheduled downtime for Service A and for Service A's host. The results were the same. Finally, as a sanity test, I did the following...

Schedule downtime for Service A's host (only host downtime) until well beyond the next set of tests.
Service A Critical hard state reached and NO notification sent
Service A Recovery hard state (Ok) reached and NO notification sent.

This begs the question though as to why a notification was sent out during a scheduled downtime window. The only difference here is that the service entered the non-OK hard state before the downtime began. If all events occurred within the downtime window, it worked exactly as expected.

In my opinion, this appears to be a bug in the code, but I'm willing to listen to reasoning as to why it would behave in this fashion. This appears to be a seldom encountered scenario, however, if you forgot to schedule down time for something until after you started maintenance, it's kind of a pain to get these notifications while you're in the outage window and there doesn't appear to be any way to stop them unless you specifically disable notifications for the service.

0000085: nagios reload during a started flexible downtime ends the downtime

Hi,

if you reload the nagios process after a started flexible downtime, the downtime has ended after the reload.

Example:

schedule a flexible downtime from 1pm to 8 pm for 2 hours
service or host is maintained at 2 pm
nagios service is either restarted or reloaded at 3 pm
service or host is after the reload no longer in a downtime, even it should be another hour.

Thorsten

0000366: Nagios keeps sending alerts when flexibile downtime is setup from external command

Actually, I am calling it via Check_MK Livestatus:

Example from the bash script:
SCHEDULE_SVC_DOWNTIME;$hostman;$serviceman;$now;$nowplus120secs;0;0;120;Manipulator script;Reconstructing"

Service goes to flexibile downtime and alerts are still coming
SCHEDULE_SVC_DOWNTIME;$hostman;$serviceman;$now;$nowplus120secs;1;0;120;Manipulator script;Reconstructing"

Fixed downtime, no alerts (for me it acts as a workaround)