monitoring-plugin-perl/lib/Monitoring, branch masterMonitoring::Plugin
https://www.monitoring-plugins.org/repositories/monitoring-plugin-perl/atom?h=master2020-09-14T08:52:29ZHandling if only the warning or critical is set2020-09-14T08:52:29ZA Codeweavers Infrastructure Bod36475663+infraweavers@users.noreply.github.com2020-09-14T08:52:29Zurn:sha1:1b5dbf6c09952a69843e08bd8943506e98bcfe1aWe think it is better to always have a threshold object implicitly created when warning and critical is passed in, so that order of execution between $mp->check_threshold and $mp->add_perfdata doesn't matter2020-09-09T12:21:25ZA Codeweavers Infrastructure Bod36475663+infraweavers@users.noreply.github.com2020-09-09T09:59:13Zurn:sha1:0b62478ad269cc6042dfc411619cfe0f6c9517aarelease 0.402018-07-25T20:16:18ZSven Nierleinsven@nierlein.de2018-07-25T20:16:18Zurn:sha1:f11af14b6d68fd752cf74cd1ebb397688abbed7eFail with config ->errstr() when undef read2018-05-24T01:01:21ZTom Rydertom@sanctum.geek.nz2018-05-24T01:01:21Zurn:sha1:301a3564e6b7cf716b75440c5333e688ea814873
The Config::Tiny parent class for Monitoring::Plugin::Config does not
necessarily raise an exception in $@/$EVAL_ERROR on a failed call to its
->read() method. Indeed, it does not in most cases, at least in the most
recent Config::Tiny.
If a file does not exist or for whatever other reason cannot actually be
read--such as permissions problems--Monitoring::Plugin ends up reporting
a "Missing config section" to the caller, which is misleading.
This information is available from the ->errstr() method of the base
class, however, and an inspection of the code for the ->read() method in
the parent class suggests the correct approach is to look for a return
of `undef` from the ->read() method, and use the return value of
->errstr() as the reported error for ->_die(). This commit adds such a
check.
To reproduce, given the following plugin `mptest`:
use strict;
use warnings;
use Monitoring::Plugin qw(%ERRORS);
my $mp = Monitoring::Plugin->new(
usage => '',
);
$mp->getopts;
$mp->plugin_exit($ERRORS{OK}, 'Done!');
Running it without options of course works, like so:
$ perl mptest
MPTEST OK - Done!
However, prior to this patch, if we specify --extra-opts with a
nonexistent filename, we get a misleading error:
$ perl mptest --extra-opts=@/nonexistent
Invalid section 'mptest' in config file '/nonexistent'
With this patch included, the error is more accurate and helpful:
$ perl mptest --extra-opts=@/nonexistent
Failed to open file '/nonexistent' for reading: No such file or directory
Remove "experimental" tag on "Message Methods"2018-03-04T20:59:29ZTom Rydertom@sanctum.geek.nz2018-03-04T20:56:22Zurn:sha1:77de65e149c519f551e03e11c9c26605c9866b72
From a maintainer, Sven Nierlein:
> I'd say we can remove the "experimental" tag there. It had been there
> for years now and i see no reason why we would change them.
Partly resolves #14.
Remove "scalar" call entirely2017-12-16T01:09:16ZTom Rydertom@sanctum.geek.nz2017-12-16T01:09:16Zurn:sha1:da6fe80e84a20aaf405a89bd0203d9ce1abc097d
Context with the lhs of the == operator forces this into scalar context
anyway, making this call redundant.
Pass params validation by ref not copy2017-12-16T00:34:38ZTom Rydertom@sanctum.geek.nz2017-12-16T00:34:38Zurn:sha1:6518f384cc20561ddc0df32414a714164dd2eb95
Since Params::Validate::validate() doesn't seem to actually mess with
this specification, may as well pass a reference rather than bother
copying the whole thing.
Remove unneeded params around "scalar" call2017-12-16T00:30:52ZTom Rydertom@sanctum.geek.nz2017-12-16T00:30:52Zurn:sha1:afa636bc749f76aed77380d39269bceecdd879d2
Operator precedence allows leaving these out.
Refactor positional arg parsing for Getopt::arg()2017-12-16T00:25:34ZTom Rydertom@sanctum.geek.nz2017-12-16T00:25:34Zurn:sha1:c3f2a7cd7313868166ba205e9eff2b8be6a36ea4
Define the expected order of parameters by key in an array, and then
apply hash slices to validate and assign the arguments including their
required flags in one swoop, again hinging on the parameter definitions
established in c1046ba.
Change arg() param type detect to key exists check2017-12-16T00:08:44ZTom Rydertom@sanctum.geek.nz2017-12-16T00:08:44Zurn:sha1:40d5fbea30c310004233ef4cd3e570c351c54233
Use the parameter label definitions from commit c1046ba to simplify the
block of code that checks whether the first argument passed to arg() is
one of the known param keys, rather than using a regular expression with
alternating expression.
This is more compact, may be marginally faster, and will make adding new
parameters to this method more straightforward in future, avoiding the
situation corrected in commit 4aa2aee.