2. RE: Error message, FileSystem template (SSH Linux)

Does it work with just the simple DF command? I've not gotten to the point I can troubleshoot that complex command very well as well, but I've been able to work around it by using a simpler command line.

3. RE: Error message, FileSystem template (SSH Linux)

Excellent suggestion to test first with a very simple command like df to check that the authentication is setup correctly.

Then I would try running zencommand standalone in debug and checking the output. You don't say whether you are on Zenoss 4.x or earlier, or on 5 or 6 (the dockerized versions). If on Zenoss 4 or less, from a command line, for a device called fred.class.example.org, use:

then check /tmp/fred. The --showfullcommand should reveal the exact command sent, complete with parameter substitution. It's almost certainly a glitch with parameter substitution, quoting or special characters in the bash command, once you have eliminated basic authentication issues.

If you are on a Zenoss 5 or 6, you will need to attach to the zencommand container first with:

4. RE: Error message, FileSystem template (SSH Linux)

Thanks for the suggestion on running just "df -kP" which I already have (did again just to be sure), but same error.I did post version in my post (Zenoss 6.1.0 r46) and running the debug did not get me any closer to the problem.

I'm not sure what to look for in that file (contains a LOT), but searching for "df" did not work (noting found except some other words containing df).

Excellent suggestion to test first with a very simple command like df to check that the authentication is setup correctly.

Then I would try running zencommand standalone in debug and checking the output. You don't say whether you are on Zenoss 4.x or earlier, or on 5 or 6 (the dockerized versions). If on Zenoss 4 or less, from a command line, for a device called fred.class.example.org, use:

then check /tmp/fred. The --showfullcommand should reveal the exact command sent, complete with parameter substitution. It's almost certainly a glitch with parameter substitution, quoting or special characters in the bash command, once you have eliminated basic authentication issues.

If you are on a Zenoss 5 or 6, you will need to attach to the zencommand container first with:

Thanks for the suggestion on running just "df -kP" which I already have (did again just to be sure), but same error.I did post version in my post (Zenoss 6.1.0 r46) and running the debug did not get me any closer to the problem.

I'm not sure what to look for in that file (contains a LOT), but searching for "df" did not work (noting found except some other words containing df).

Excellent suggestion to test first with a very simple command like df to check that the authentication is setup correctly.

Then I would try running zencommand standalone in debug and checking the output. You don't say whether you are on Zenoss 4.x or earlier, or on 5 or 6 (the dockerized versions). If on Zenoss 4 or less, from a command line, for a device called fred.class.example.org, use:

then check /tmp/fred. The --showfullcommand should reveal the exact command sent, complete with parameter substitution. It's almost certainly a glitch with parameter substitution, quoting or special characters in the bash command, once you have eliminated basic authentication issues.

If you are on a Zenoss 5 or 6, you will need to attach to the zencommand container first with:

Thanks for the suggestion on running just "df -kP" which I already have (did again just to be sure), but same error.I did post version in my post (Zenoss 6.1.0 r46) and running the debug did not get me any closer to the problem.

I'm not sure what to look for in that file (contains a LOT), but searching for "df" did not work (noting found except some other words containing df).

Excellent suggestion to test first with a very simple command like df to check that the authentication is setup correctly.

Then I would try running zencommand standalone in debug and checking the output. You don't say whether you are on Zenoss 4.x or earlier, or on 5 or 6 (the dockerized versions). If on Zenoss 4 or less, from a command line, for a device called fred.class.example.org, use:

then check /tmp/fred. The --showfullcommand should reveal the exact command sent, complete with parameter substitution. It's almost certainly a glitch with parameter substitution, quoting or special characters in the bash command, once you have eliminated basic authentication issues.

If you are on a Zenoss 5 or 6, you will need to attach to the zencommand container first with:

7. RE: Error message, FileSystem template (SSH Linux)

type: <class 'twisted.internet.error.ReactorNotRestartable'> is the error? If that is the case, something is stopping the twisted reactor. Working after a restart would make sense, since everything gets restarted and the reactor will be running again, executing commands.

You said it works once, how do you know it works once?

Can you post the output (scrubbed) of a zencommand run -d<deviceId> --showfullcommand

Are you running tests from the datasource? If so, can you restart zencommand, then not run any tests and see if things start graphing

Thanks for the suggestion on running just "df -kP" which I already have (did again just to be sure), but same error.I did post version in my post (Zenoss 6.1.0 r46) and running the debug did not get me any closer to the problem.

I'm not sure what to look for in that file (contains a LOT), but searching for "df" did not work (noting found except some other words containing df).

Excellent suggestion to test first with a very simple command like df to check that the authentication is setup correctly.

Then I would try running zencommand standalone in debug and checking the output. You don't say whether you are on Zenoss 4.x or earlier, or on 5 or 6 (the dockerized versions). If on Zenoss 4 or less, from a command line, for a device called fred.class.example.org, use:

then check /tmp/fred. The --showfullcommand should reveal the exact command sent, complete with parameter substitution. It's almost certainly a glitch with parameter substitution, quoting or special characters in the bash command, once you have eliminated basic authentication issues.

If you are on a Zenoss 5 or 6, you will need to attach to the zencommand container first with:

type: <class 'twisted.internet.error.ReactorNotRestartable'> is the error? If that is the case, something is stopping the twisted reactor. Working after a restart would make sense, since everything gets restarted and the reactor will be running again, executing commands.

You said it works once, how do you know it works once?

Can you post the output (scrubbed) of a zencommand run -d<deviceId> --showfullcommand

Are you running tests from the datasource? If so, can you restart zencommand, then not run any tests and see if things start graphing

Thanks for the suggestion on running just "df -kP" which I already have (did again just to be sure), but same error.I did post version in my post (Zenoss 6.1.0 r46) and running the debug did not get me any closer to the problem.

I'm not sure what to look for in that file (contains a LOT), but searching for "df" did not work (noting found except some other words containing df).

Excellent suggestion to test first with a very simple command like df to check that the authentication is setup correctly.

Then I would try running zencommand standalone in debug and checking the output. You don't say whether you are on Zenoss 4.x or earlier, or on 5 or 6 (the dockerized versions). If on Zenoss 4 or less, from a command line, for a device called fred.class.example.org, use:

then check /tmp/fred. The --showfullcommand should reveal the exact command sent, complete with parameter substitution. It's almost certainly a glitch with parameter substitution, quoting or special characters in the bash command, once you have eliminated basic authentication issues.

If you are on a Zenoss 5 or 6, you will need to attach to the zencommand container first with:

9. RE: Error message, FileSystem template (SSH Linux)

It seems to be working now after just restarting, and not testing the setup.The only thing left now is that it comes an error message now and then from *all* servers;Unable to process COMMAND datasource(s) for device XYZ -- skipping

It is connected to this, because if I disable the command for file system (disk/idisk) the message is not coming anymore, but also no data of course.

type: <class 'twisted.internet.error.ReactorNotRestartable'> is the error? If that is the case, something is stopping the twisted reactor. Working after a restart would make sense, since everything gets restarted and the reactor will be running again, executing commands.

You said it works once, how do you know it works once?

Can you post the output (scrubbed) of a zencommand run -d<deviceId> --showfullcommand

Are you running tests from the datasource? If so, can you restart zencommand, then not run any tests and see if things start graphing

Thanks for the suggestion on running just "df -kP" which I already have (did again just to be sure), but same error.I did post version in my post (Zenoss 6.1.0 r46) and running the debug did not get me any closer to the problem.

I'm not sure what to look for in that file (contains a LOT), but searching for "df" did not work (noting found except some other words containing df).

Excellent suggestion to test first with a very simple command like df to check that the authentication is setup correctly.

Then I would try running zencommand standalone in debug and checking the output. You don't say whether you are on Zenoss 4.x or earlier, or on 5 or 6 (the dockerized versions). If on Zenoss 4 or less, from a command line, for a device called fred.class.example.org, use:

then check /tmp/fred. The --showfullcommand should reveal the exact command sent, complete with parameter substitution. It's almost certainly a glitch with parameter substitution, quoting or special characters in the bash command, once you have eliminated basic authentication issues.

If you are on a Zenoss 5 or 6, you will need to attach to the zencommand container first with: