Hi Suzanne,
Hope you are doing fine today!
I took a look over the mentioned QCR and some other related cases for this matter and did a summary from some of the internal discussions about this matter:
All of our job types have internal timeouts around the execution of actions (internally we call them commands) against managed servers, the change that occurred around 10.23 was that the "Command Engine" (waybot) will not give up on one of these managed server actions (commands) as long as the agent reports that it is still working on the action.
This effectively prevents the parent job from every timing out, if some sort of hang occurred on the agent side, the purpose of this new parameter is to allow a configurable middle ground between the old behavior and the new behavior.
A value of 0 means to effectively use the old behavior.
Now the old behavior was for the job to mark the action (command) against the managed server as failed after the timeout was reached... regardless of whether or not the action was still executing on the agent side.
this behavior is arguably undesirable as the job report in HPSA is *implying* that all work related to the job is complete. yet, it is possible that there could still be actions executing on managed servers that the job was executed against.
a simple example would be if you ran a server script with say "while true; do sleep 1; done". that script will never end, pre 10.23, the job would register a completed status after the specified timeout; post 10.23, the job will continue to remain active as long as the agent reports that it is still executing the script.
(actually there might be an agent side timeout for server scripts whereby the agent's batchbot will kill the child process after the timeout period. but the idea is still a good analogy.)
So a value of 0 says to effectively use the old behavior, HPSA will provide no "grace" for running beyond the specified timeout for the action against the managed server, a value of -1 means to effectively use the new post 10.23 behavior; positive values are the middle ground.
This is totally up to the customer, if they want to use a positive value, or 0, or -1.
We have no way of providing a "recommended" positive value. but we can explain what the different values mean, and the customer can decide, A value of 3600 means that the waybot will wait an additional 3600 minutes past the specified timeout for the managed server action.
Most of our timeouts around actions that involve implicit software/patch listings are usually around 1800s. so if the WUA interaction ends up taking 45 minutes, then with the old behavior the command would have been cancelled. WIth the new post 10.23 behavior, the job would have been held as ACTIVE until the command finally completed.
if the grace_timeout was set to say 1800, then a command that ended up taking 45 minutes would end up registering the completion of the over-run action (command).
Hope this helps,
Regards,
Manfred Monge
Customer Support Engineer
If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
