The check_disk fails if the build system has more than 100GB of free disk
space. Lets make this 100TB and we are safe for a couple more years.
Signed-off-by: Sven Nierlein <sven@nierlein.de>
snmp tests fail if the snmp daemon runs systemd, then the process with 1 has arguments. Convert
the test into a regex which works for sysv and systemd.
Signed-off-by: Sven Nierlein <sven@nierlein.de>
Enabled snmp tests against snmpd on localhost. It was installed already
in the travis file, we just need to enable the tests by setting the
parameters in the answers file.
Signed-off-by: Sven Nierlein <sven@nierlein.de>
* maint:
sslutils: Remove superfluous parenthesis for sslv3 function too
sslutils: remove superfluous parenthesis
check_snmp: modified tests
check_snmp.c: switched DEFAULT_TIMEOUT to DEFAULT_SOCKET_TIMEOUT (provided by utils.h), already used by help description, see issue #1318
install snmpd on travis tests
enable libtab on travis builds
add perl snmp to travis dependencies
NEWS: Mention check_ups performance data fix
Fix incorrect performance data thresholds
check_dhcp: Fix option parsing
Fixes segfaults when running via monitoring worker (off-by-one)
travis: fix http test host
sslutils: Check if OpenSSL supports SSLv3.
Conflicts:
NEWS
plugins/sslutils.c
Forking raises a race condition, where the parent might run the
test before the child has had time to fork. If that happens,
an error similar to this is produced:
Failed test 'Output correct'
at ./t/check_procs.t line 32.
'PROCS OK: 0 processes with args 'sleep 7' | processes=0;;;0;'
doesn't match '/^PROCS OK: 1 process?/'
Sleeping a bit should avoid the problem. It might be enough to
sleep less than a second, but perl's built-in sleep function only
supports integer seconds.
In our build environment, the build failed 3 of 4 times before
this patch. After the patch it failed 0 of 7 times.
Signed-off-by: Mikael Falkvidd <mfalkvidd@op5.com>
The SNMPv3 noAuthNoPriv security level, somewhat unintuitively, requires
a security name to be passed along together with the request. Check_snmp
previously did not do this, causing snmpget to throw an error:
"External command error: No log handling enabled - turning on stderr
logging
snmpget: No securityName specified"
This patch fixes the issue by always providing the security name when
noAuthNoPriv is specified.
See also:
https:://bugs.op5.com/view.php?id=8385.
Signed-off-by: Anton Lofgren <alofgren@op5.com>
Also default to "-u test -ptest" which are default MySQL accounts only
missing the prescribed privileges.
The database is no longer specified as it is not used.
If wanted is should be its own parameter/tests.
* maint:
check_ssh: Get rid of sshd: Read from socket failed: Connection reset by peer
fixed tests when there is no direct internet connection
NEWS: Mention fix for check_http's -S option
Fix for SSL Versioning when multiple options are used.
Fix#1217 spec file fails to build due to duplicate files and unused files
check_http: Don't let "-N" expect an argument
README: Change GitHub URL
README: Clarify license notice
Update URLs and mailing list addresses
Just using the posix conform extended regular expression grep
check_oracle: --db +ASM bad string matching check_oracle doesn't correctly check for pmon +ASM instance from at least Oracle 11 as the pmon proces was renamed from ora_pmon_.* to asm_pmon_.*. -- Just turning attached patch of github issue #1207 into a push request. (Closes#1207)
Update web site URLs
Conflicts:
FAQ
NEWS
README
SUPPORT
configure.in
monitoring-plugins.spec.in
pkg/solaris/pkginfo.in
plugins-root/check_dhcp.c
plugins-root/check_icmp.c
plugins-scripts/check_ifoperstatus.pl
plugins-scripts/check_mssql.pl
plugins/check_apt.c
plugins/check_by_ssh.c
plugins/check_cluster.c
plugins/check_dbi.c
plugins/check_dig.c
plugins/check_disk.c
plugins/check_dns.c
plugins/check_dummy.c
plugins/check_fping.c
plugins/check_game.c
plugins/check_hpjd.c
plugins/check_http.c
plugins/check_ide_smart.c
plugins/check_ldap.c
plugins/check_load.c
plugins/check_mrtg.c
plugins/check_mrtgtraf.c
plugins/check_mysql.c
plugins/check_mysql_query.c
plugins/check_nagios.c
plugins/check_nt.c
plugins/check_ntp.c
plugins/check_ntp_peer.c
plugins/check_ntp_time.c
plugins/check_nwstat.c
plugins/check_overcr.c
plugins/check_pgsql.c
plugins/check_ping.c
plugins/check_procs.c
plugins/check_radius.c
plugins/check_real.c
plugins/check_smtp.c
plugins/check_snmp.c
plugins/check_ssh.c
plugins/check_swap.c
plugins/check_tcp.c
plugins/check_time.c
plugins/check_ups.c
plugins/check_users.c
plugins/negate.c
plugins/urlize.c
plugins/utils.h
po/Makevars
po/de.po
po/fr.po
po/monitoring-plugins.pot
This is an initial take at renaming the project to Monitoring Plugins.
It's not expected to be fully complete, and it is expected to break
things (The perl module for instance). More testing will be required
before this goes mainline.
This fixes an issue that appears when running check_procs over NRPE,
where the default shell is configured to (for example) dash, as is the
case on Debian.
dash (and tcsh, and mksh, and probably others), when invoked with -c forks an additional process
to execute the argument string. Contrast this with bash, which does not
do this, provided that the argument string simply can be exec()'d as-is.
To demonstrate:
$ bash -c pstree
init─┬ ..
...
├─sshd─-─sshd───pstree
versus
$ dash -c pstree
init─┬ ..
...
├─sshd─-─sshd───dash───pstree
The consequence of this fork is that the following invocation:
/opt/plugins/check_procs -a init
will result in this output:
PROCS OK: 2 processes with args 'init' | processes=2;;;0;
because the check_procs, in addition to finding the actual init process,
finds its parent shell as well.
This example is a bit contrived, but I think it illustrates the
point.
This wouldn't really be a problem, and normally isn't, if it weren't
for the fact that NRPE uses a call to popen() which does exactly the
above (executes '/bin/sh -c ...'), causing inconsistent behaviour
between distributions and much confusion for end users.
The argument may be made that the dash process spawned by NRPE is just a
process like any other, and should therefore be included in the process
count just like any other. However, this is not very intuitive, because
of the previously mentioned inconsistencies.
The argument might also well be made that we're _never_ interested in the
immediate ancestor of the plugin, and while it is unknown how many
installations have already made the necessary modifications to their
setups to make up for the fact that the plugin behaves the way it does,
it is not deemed worthwhile to entertain such workarounds.
Thus, this patch ignores the parent process.
See also these bug reports:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626913http://sourceforge.net/p/nagiosplug/bugs/512/https://github.com/nagios-plugins/nagios-plugins/issues/999https://bugs.op5.com/view.php?id=4398
