This adds support for @<range> and makes stuff a bit simpler by removing code
duplications.
Note: Previously, the compatibility code for 'check_procs <warn> <max>'
accepted something like 'check_procs -w 10:-1 -c 10:-1 20 50' as well
(treating it as if '-w 10:20 -c 10:50' was specified). This is no longer the
case ... additional arguments are only used as warn/crit thresholds in case
-w/-c is not specified at all.
Dying without a hint of what went wrong is just plain annoying. With
this patch we at least get a hint.
While at it, we fix the string offset so the output we're interested
in doesn't keep the equal sign that snmpget prints.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Once upon a time, check_snmp used to accept inverse ranges in the
format of '2:1' to mean "alert if value is inside this range".
Since commit 7cb3ae0933, ranges such
as those have instead triggered the error "Range format incorrect"
and resulted in an UNKNOWN warning state. This patch attempts to
fix the situation so that the old-style ranges continues to mean
exactly what the once did and people with lots of snmp checks can
avoid a bazillion false positives from their environments.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Let OpenSSL load its configuration file. See the OPENSSL_config(3) man
page for details.
(Suggested by Max Kosmach in Debian bug report #689960, forwarded by Jan
Wagner.)
Fix the threshold specifications in the example for checking the number
of truechimers.
Reported by Marc Haber on the "nagios-users" mailing list (Message-ID:
<20120722142840.GA6931@torres.zugschlus.de>).
Mention that the check_ntp_peer plugin checks the stratum of the
synchronization peer, not the stratum of the monitored server itself.
Thanks to Marc Haber for bringing this up on the "nagios-users" mailing
list (Message-ID: <20120722142840.GA6931@torres.zugschlus.de>).
The "ssl_version" variable was undeclared when the plugins were compiled
--without-openssl and --without-gnutls.
Bug reported by Michael LaCorte on the "nagiosplug-help" mailing list
(Message-ID: <CCD30C91-A2A8-463A-82A9-F99B54F741D3@gmail.com>).
A recent update removed the declarations for a couple variables in
check_smtp.c that are still being used, which caused a failure
in the compilation of check_smtp.c. This commit restores those variable
declarations so the check_smtp.c will again compile.
Earlier versions of check_smtp generated an (invalid) "MAIL FROM"
command without arguments by default. These days, a "MAIL FROM" command
is only sent if the --from option is specified.
This commit removes a comment which explains the old behaviour, and it
updates a variable name accordingly.
Fixes many instances of
warning: ignoring return value of 'asprintf', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Apparently some people used -f '<nagios@example.com>' to work around
the bug I just fixed in the MAIL FROM: command generation. Although
the resulting command wasn't RFC-compliant, it was working with some
MTAs, so let's continue to support this syntax now that we generate
RFC-compliant commands.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Every version of the SMTP standard (from RFC 821 to the current RFC
5321) requires the address following MAIL FROM: to follow the colon
immediately (with no space) and to be surrounded by angle brackets.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
When using the 1.4.15 release of the Nagios Plugins, a command such as
check_tcp -H pop.example.com -p 995 -D 14
usually produced two lines of output, e.g.:
OK - Certificate will expire on 12/13/2014 23:59.
TCP OK - 0.009 second response time on port 995|time=0.008849s;;;0.000000;10.000000
The second line was removed by 4d06603060.
However, as the old two-line output is a valid (though in this case
unintended) way to spit out performance data, removing the second line
might break current setups. Therefore, we revert to the old behaviour,
at least for the moment.
The issue was reported by Jochen Bern on the "nagiosplug-devel" mailing
list (Message-ID: <4FEAE812.8030309@LINworks.de>).
Don't return a WARNING state if the number of lost packets is greater
than zero but below the specified warning threshold. This happened
because the check_ping plugin used the exit status of the ping(1)
utility. (#3535140 - Tobias Brox)
In the C shell and in the Z shell, the "?" character must be quoted or
backslash-escaped in order to use it verbatim. Therefore, a command
such as
check_by_ssh -H test.example.com -l joe echo huh?
might fail, depending on joe's login shell on test.example.com.
Just to make sure, this commit removes most punctuation characters from
our test strings.
The ping6(1) implementation provided by Debian's iputils-ping package
may produce output such as the following:
| 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2009ms
There's a corresponding pattern in check_ping.c:458:
| "%*d packets transmitted, %*d received, +%*d errors, %d%% packet loss"
Without this fix, the pattern in check_ping.c:456 matched first (as
sscanf(3) interprets "+3" as a match for "%d"):
| "%*d packets transmitted, %*d received, %d%% loss, time"
(#1894850 - Debian bug report #514588 - Matej Vela)
This metric compares the database engine server version with the specified
ranges. The version string [[[[A.]B.]C.]D.]E[.] is returned as E + D*100 +
C*10000 + B*1000000 + A*100000000 (see libdbi's dbi_conn_get_engine_version()
documentation).
These options may be used to specify an extended POSIX regular expression that
is applied to the query result. When using -R, a case-insensitive match is
done.
The options may not be mixed with -w/-c/-e.
This option may be used to specify a string that is expected as the query
return value. The string is compared to the query result using strcmp().
The option may not be mixed with -w/-c.
This metric checks the execution time of the specified query. In case the
query does not return any (parsable) data, this is not treated as an error
when using this metric.
The -m option may be used to specify a metric to check the thresholds against.
This is more flexible than --conntime-warning/--conntime-critical (-W/-C) as
it may be extended to support further metrics without introducing tons of
arguments. Also, it does not make much sense to check the conntime and query
result at the same time.
Currently, the metrics CONN_TIME and QUERY_RESULT are available.
A query is no longer required unless QUERY_RESULT (the default) is used.
