The following code runs under QnA on Linux servers and returns the correct process status of “Running”. When I run the same code from the Fixlet Debugger using the channel client, or run it as a property from within an analysis in BES 11.2 I get an incorrect status of “Stopped”. I am copy/pasting the code to eliminate typos when testing. What am I missing?
if unix of operating system then If exists processes whose (name of it as string as lowercase = "processd") then "Running" else "Stopped" else "OS Unknown"
It’s probably a difference in whether the query is evaluated “in client context” or in debugger context.
If I recall correctly, when we run qna manually on the Linux machine, inspectors like ‘processes’ basically give the same results as ‘ps’ - i.e. the processes are filtered to those in your session/user account. ‘ps’ might only show the shell and QNA.
When run in an Analysis, or with the “Use Client Context” it behaves more like ‘ps -ef’, giving details of all the processes on the machine.
When using the WebUI Query app, select the “Evaluate by Agent” option to get the most accurate results; but it will be a bit slower.
1 Like
I’ll check the web UI.
EDIT: WebUI returns STOPPED for a RUNNING process/PID
Note, I have two other properties for different processes, using the same relevance code but with a different process PIDs, that are working as expected.
Thoughts?
Emil
I’m not sure what “processd” is, is it possible it’s quickly stopping and restarting or something like that and we’re not catching the timing right?
processd is a placeholder, for security reasons, for the actual process I am interrogating. BTW, “PS -au root” | grep processed" as well as “ps -ef | grep processed”, return the running process correctly from the terminal.
Thanks for you help,
Emil
Emil
Found the problem.
The process name reported by the BES Client is processd65432 rather than processed. I changed the = “processed” to contains processed and all is groovy now.
Emil
1 Like
Excellent! Thanks for posting back with your solution.
