Created attachment 574939 [details] agent.log showing result of "plugins update" operations -- see 2012-04-03 11:14:23,535 Description of problem: Running certain agent prompt commands through the "Execute Prompt Command" option in the server UI (e.g. "plugins update") is reported as having failed with the stack-trace below, even though the command appears to have been executed successfully, based on the agent's log file. java.lang.RuntimeException: Call to [org.rhq.plugins.agent.AgentServerComponent.invokeOperation()] with args [[executePromptCommand, Configuration[id=10241]]] was rudely interrupted. at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invokeInNewThreadWithLock(ResourceContainer.java:479) at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invoke(ResourceContainer.java:461) at $Proxy55.invokeOperation(Unknown Source) at org.rhq.core.pc.operation.OperationInvocation.run(OperationInvocation.java:217) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1042) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326) at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:257) at java.util.concurrent.FutureTask.get(FutureTask.java:119) at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invokeInNewThreadWithLock(ResourceContainer.java:473) ... 6 more Version-Release number of selected component (if applicable): JON Server 3.0.0.GA and Agent 4.2.0.JON300.GA How reproducible: Always Steps to Reproduce: 1. Install server and agent. 2. Import agent into server inventory 3. Click on "Operations" tab for agent. 4. Schedule a new "Execute Prompt Command" operation and set the prompt command to be "plugins update" 5. Notice that the operation is listed as having failed under "History" in the server UI, but the agent's agent.log appears to show it as having succeeded. Actual results: Successful operation reported as unsuccessful on server. Expected results: If the operation was executed successfully, the status for the operation should reflect this. Additional info: I tried setting the "Timeout" value to 30 seconds when scheduling the operation, but the status still shows up as "Failed" immediately after scheduling the operation (operation was scheduled as "Now").
Removing from rhq tracker, and raised upstream rhq bug #810911, to try to reproduce
I think this is because updating plugins requires the plugin container to shutdown and restart. Due to the shutdown, I think this will happen. To work around this, we could try to update the plugins asynchronously, allowing the operation invokation method to return immediately with a success code.
(In reply to comment #2) > I think this is because updating plugins requires the plugin container to > shutdown and restart. Due to the shutdown, I think this will happen. > > To work around this, we could try to update the plugins asynchronously, > allowing the operation invokation method to return immediately with a success > code. Hmm... looking at the code, it seems like it is preparing itself for the PC shutdown. Not sure why this bug is happening.
According to bug 692933 (listed as a "See Also"), the same thing apparently happens when running stopping the plugin container (pc stop).
(In reply to comment #4) > According to bug 692933 (listed as a "See Also"), the same thing apparently > happens when running stopping the plugin container (pc stop). yeah, anything that kills the plugin container needs to be handled special. Because the plugin is the thing that handles the operation invocation, and if the operation kills the plugin container, its killing the very same thing that is handling the operation :)
Makes sense :)
oh, you know, I just realized this BZ is talking about the "Execute Prompt Command" ! Yes, in that case, this is definitely to be expected. Rather than use "plugins update" prompt command, you should directly invoke the "Update All Plugins" operation (this performs the "plugins update" asynchronously). Same thing with the "pc" command - there is a "Restart Plugin Container" operation to use instead. Note that it doesn't make sense to do a remote "pc stop" because that will effectively make the agent dead in the water since once you stop the PC you can't remotely start it back up again (because the PC is down! It can't service any more remote calls like "pc start") I think we should close this as WONTFIX. The behavior is to be expected simply by the nature of the prompt command attempting to be executed. We already have a "Update All Plugins" operation you can use to do this plugin update so there is no need to use Execute Prompt Command here.
if we want to avoid users doing this, I can change the Execute Prompt command operation implementation to look at the command being invoked and if its one of the commands that kill the PC, I can fail with an error message saying something like "don't do that". This would be things like: plugins update pc restart shutdown pc stop We have analogous first-class operations on the RHQ Agent that lets you do this already: Update All Plugins Restart Plugin Container Shutdown Agent We don't have anything analogous to "pc stop", but this is really not for production usage anyway - the "pc stop" command was for developers to use during debugging.
I was actually thinking of requesting something like. I think having a more descriptive error message would go a long way, in this case.
The same exception will happen when executing "inventory --sync" as "Execute Prompt Command".