monitoring-plugins, branch v2.3.3Monitoring Plugins
https://www.monitoring-plugins.org/repositories/monitoring-plugins/atom?h=v2.3.32023-02-01T13:40:55ZPreaparing Release 2.3.32023-02-01T13:40:55ZJan Wagnerwaja@cyconet.org2023-02-01T13:40:55Zurn:sha1:1a964086aacce594ea73a641620ccfdc98782105Update release doc to recent versions2023-02-01T13:10:17ZJan Wagnerwaja@cyconet.org2023-02-01T13:10:17Zurn:sha1:e88a2889da629674368378411580363a4b403ce1Merge pull request #1830 from monitoring-plugins/fix_18292023-01-31T11:18:14ZLorenz12514511+RincewindsHat@users.noreply.github.com2023-01-31T11:18:14Zurn:sha1:2ad962c13473607ca0d974bfaa516a0ed53ec73d
check_http: Fix memory reallocation error in chunk decoding logiccheck_http: Add space for ending NULL byte in array for chunked encoding2023-01-30T12:33:46ZLorenz Kästle12514511+RincewindsHat@users.noreply.github.com2023-01-30T12:33:46Zurn:sha1:d3fbcd122012af7733de3b80a692f79ad69057b2check_http: Fix memory reallocation error in chunk decoding logic2023-01-30T11:45:20ZLorenz Kästle12514511+RincewindsHat@users.noreply.github.com2023-01-30T11:45:20Zurn:sha1:d9528c265b96a5a0f0c2e43ac74ab3921a2987e1
This patch should fix an error with the way memory reallocation was
used, which resulted in "realloc(): invalid next size".
It is not completely clear to me as to what caused this problem, but
apparently one can not depend handing a pointer to "realloc(3)" and
expect that it still works afterwards, but one should/must use the one
returned by the function.
Also this patch replaces a variable which was used to remember the
position in the array by just computing that from the current values.
check_disk: Clarify usage possibilites (#1745)2023-01-20T11:08:15ZLorenz12514511+RincewindsHat@users.noreply.github.com2023-01-20T11:08:15Zurn:sha1:67b472f9d1d29b9de5312c46f13ca4f5a656c4da
* Clarify usage possibilites of check_disk
* Remove superfluous newlines
Co-authored-by: waja <waja@users.noreply.github.com>add tests for check_log2023-01-20T08:11:26Zlorenzglorenz.gruenwald@consol.de2023-01-20T07:52:38Zurn:sha1:c410ad38798fde8cc278a3f1522a9571dbdb7faeFix indents2023-01-20T08:11:26Zlgmu80966566+lgmu@users.noreply.github.com2023-01-19T10:37:45Zurn:sha1:b153a8c499802c2fdba199e84f5f7426ff4c0748Added --exclude, cleanup args, fix -a count bug2023-01-20T08:11:26Zlgmu80966566+lgmu@users.noreply.github.com2023-01-19T10:33:25Zurn:sha1:db1f87c39e0ff0d76d13babfcbb332c4cc3ad0fe
Added --exclude to exclude patterns
Cleaned up duplicated code in the args
Fixed a bug when using --all because the count always returned "1" even when nothing matched
entry=$($GREP "$query" "$tempdiff")
count=$(echo "$entry" | wc -l)
Example:
$ touch testfile
$ TEST123=$(grep 'test' testfile)
$ echo "$TEST123" | wc -l
1fix check_snmp regex matches2023-01-20T07:57:56ZSven Nierleinsven@nierlein.de2023-01-19T22:29:01Zurn:sha1:f4930aee28ccb664691809e7dcc9198eb81429c5
the multiplier function always tried to extract a number, even if the result
is a string because of using a mib.
before:
```
./check_snmp -H hostname -P2c -c public -o IF-MIB::ifAdminStatus.11466 -vvv -r 0
/usr/bin/snmpget -Le -t 10 -r 5 -m ALL -v 2c [context] [authpriv] 10.0.13.11:161 IF-MIB::ifAdminStatus.11466
IF-MIB::ifAdminStatus.11466 = INTEGER: up(1)
Processing oid 1 (line 1)
oidname: IF-MIB::ifAdminStatus.11466
response: = INTEGER: up(1)
SNMP OK - 0 | IF-MIB::ifAdminStatus.11466=0;;
```
the regexp 0 matches, even if the actual result is "up(1)".
after this patch:
```
./check_snmp -H hostname -P2c -c public -o IF-MIB::ifAdminStatus.11466 -vvv -r 0
/usr/bin/snmpget -Le -t 10 -r 5 -m ALL -v 2c [context] [authpriv] 10.0.13.11:161 IF-MIB::ifAdminStatus.11466
IF-MIB::ifAdminStatus.11466 = INTEGER: up(1)
Processing oid 1 (line 1)
oidname: IF-MIB::ifAdminStatus.11466
response: = INTEGER: up(1)
SNMP CRITICAL - *up(1)* |
```