You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was really looking forward to the functionality promised by --unknown-timeout (-U) implemented by #1123 and #1774.
But ./check_by_ssh -H 192.168.x.y -U -C true still returns: "CRITICAL - Plugin timed out after 10 seconds"
I've checked the source code and found out that it returns UNKNOWN only if SSH returns 255, i.e. it has its own timeout set below the timeout of the plugin, e.g. ./check_by_ssh -H 192.168.x.y -U -oConnectTimeout=9 -C true. Without that, ssh times out after 3 minutes (YMMW), while the plugin usually times out much sooner, and returns CRITICAL even if -U is set.
So it would make sense, to set -oConnectTimeout to 1s less than the timeout on the plugin (-t). At least if -U is specified, but preferably always.
OTOH, there are situations, when the connection is established (at least on TCP level), and the processing of the remote command takes too long - i.e. due to high load, or DNS problems. Those cases are not catched by -oConnectTimeout, and again result in CRITICAL, regardless of -U setting. But this may be desirable in some situations.
Please consider either
a) setting -oConnectTimeout automatically
b) (maybe separate) function to report UNKNOWN even if the remote command takes too long to process
Thank you
Vladislav Kurz
The text was updated successfully, but these errors were encountered:
I was really looking forward to the functionality promised by --unknown-timeout (-U) implemented by #1123 and #1774.
But
./check_by_ssh -H 192.168.x.y -U -C true
still returns: "CRITICAL - Plugin timed out after 10 seconds"I've checked the source code and found out that it returns UNKNOWN only if SSH returns 255, i.e. it has its own timeout set below the timeout of the plugin, e.g.
./check_by_ssh -H 192.168.x.y -U -oConnectTimeout=9 -C true
. Without that, ssh times out after 3 minutes (YMMW), while the plugin usually times out much sooner, and returns CRITICAL even if -U is set.So it would make sense, to set -oConnectTimeout to 1s less than the timeout on the plugin (-t). At least if -U is specified, but preferably always.
OTOH, there are situations, when the connection is established (at least on TCP level), and the processing of the remote command takes too long - i.e. due to high load, or DNS problems. Those cases are not catched by -oConnectTimeout, and again result in CRITICAL, regardless of -U setting. But this may be desirable in some situations.
Please consider either
a) setting -oConnectTimeout automatically
b) (maybe separate) function to report UNKNOWN even if the remote command takes too long to process
Thank you
Vladislav Kurz
The text was updated successfully, but these errors were encountered: