Passing arguments to Powershell

[WillemDH]

I did all the latest tests again after applying the config in the XI gui. But it still don't give me the same result as the cli, even when using exactly the same path.

[sreinhardt]

After some testing, it seems that using single quotes will attempt to output the litteral string, where as double quotes will output the escaped string. We got XI working as you need it by using "\\\\stad\namespace\\share" Try giving that a shot and let me know!

[WillemDH]

Hello,

Thanks again for looking into this. So I did some new tests. As my Powershell script outputs the dfsshare, i'll copy the output here. I did all the tests by "scheduling an immediate" check for the service in nagios XI, so I'm not using the 'test' option in CCM.
The command is $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -t 120 -c check_dfs_foldersize -a "$ARG1$" "$ARG2$"
The configuration of the external command in nsclient.ini is check_dfs_foldersize=cmd /c echo scripts\check_dfs_foldersize.ps1 $ARG1$; exit $LastExitCode | powershell.exe -command -"
So the argument I need in Powershell has to be like this: \\stad\namespace\share

Using "\\\\stad\\namespace\\share" gives dfspad: \\stadnamespaceshare
Using "\\\\stad\namespace\share" gives dfspad: \\stadnamespaceshare

Doing these tests, I was thinking maybe the command doesn't need the ", so I changed the command in $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -t 120 -c check_dfs_foldersize -a $ARG1$ $ARG2$
And did the tests again:

Using "\\\\stad\namespace\share" gives dfspad: \\stadnamespaceshare
Using "\\\\stad\\namespace\\share" gives dfspad: \\stad\\namespace\\share

As this was still not working, I changed the " into ' and did the tests again:

Using '\\\\stad\namespace\share' gives dfspad: \\stadnamespaceshare
Using '\\\\stad\\namespace\\share' gives dfspad: \\\\stad\\namespace\\share

BUT apparently my ps script can handle \\\\stad\\namespace\\share as I do get an output! Gonna do some more tests and add the performance data. I think nagios XI might add a \ to a \ when echoing data, so when XI shows \\ , it is actually a \...

[sreinhardt]

Could you post your nsc.ini or nsclient.ini file please, also if you have logging enabled nsclient logs could be helpful. We would like to check a few different settings and options that could be in place. As always feel free to sanitize as needed. Glad you picked up on that I meant \\\\test\\path\\file instead of the single \ in the middle. This is very strange that even with the testing we did here, that it is not sending to nsclient properly.

[WillemDH]

Hello again, you answer to quick I edited my post above, I think i'm getting there with single quotes. Still testing though.

[slansing]

Ah excellent! Let us know how progress goes, if you run into another wall please post your NSC.ini file blocking out sensitive information.

[WillemDH]

Well I'm getting there.. Just ran into some new issues. The dfs share I tested with is relatively small. So I started testing on the DFS share that need to be checked an apprently it's full of folders whose path islonger then 255 characters causing errors in the script output causing Nagios to flip... Looking for a solution to catch and dismiss errors atm.

[sreinhardt]

Awesome to hear you got the path passed correctly! As for the character limit, there isn't too much you can do. I suppose my suggestion would be to modify the powershell script to check length, and if past 255 to send a message without the path back. It really shouldn't be too bad. Something along the lines of:

Code: Select all

If ( $folderpath.length() -gt 250 ) {
     SendShortMessage($result);
} Else {
     SendFullMessage($result);
}

As it would be the result of only one service at a time anyway, it should not be confusing as to what the result is for.

[WillemDH]

Hello,

Ok, from one problem into the next..

I managed to solve the errors caused by too long paths by adding -ErrorAction SilentContinue

Code: Select all

$folderlist = Get-ChildItem $dfspad -Recurse -ErrorAction SilentlyContinue | Measure-Object -property length -sum

But then I got the following error when scheduling a check: CHECK_NRPE: Received 0 bytes from daemon

After chatting with Michael Medin about it, he let me know I probably had some timeout issue. Apparently, there are 4 different places to configure these timeouts.
1) In the command definition with "-t 300"
2) in [settings/NRPE/server] with timeout=300
3) In [settings/external scripts] with timeout=300
3) In nagios.cfg (see http://nagios.sourceforge.net/docs/3_0/ ... ck_timeout )
with service_check_timeout=300

But even after changing all these timeouts, I still get a timeout..

Ok, small correction. After a reboot of the server, I don't get any timeouts anymore...

But now one more question: Is there any impact I'm not seeing by changing the service_check_timeout to 300? I can imagine some (more critical) services that might require small timeouts?

And one more question, I can imagine I'll need to write script who take even longer to execute. How should I handle this? it seems unlikely to make this timeout even longer. is there no possibility to change the timeout only for some particular services? It seems strange this is a global timeout.

[sreinhardt]

I'm going to answer this in reverse order. As for longer scripts, and even possibly this one if you are worried about timeout, I would highly suggest using a passive agent like nrds or nsca instead of an active client. This way you can have that remote agent run the script in any amount of time it takes, and when it returns, it sends back the data to nagios and no one is the wiser that it took a long time.

As for more critical checks needing shorter timeouts, that is entirely up to you. I would agree that 300 seconds is a long time and seems a bit excessive. At the same time, many checks do allow for a -t flag that can specify an individual timeout. This is an option, but a bit tedious to change everything to shorter timeouts. Again I would probably suggest the passive client route instead.

Glad to hear this is finally working!!