#!/bin/sh # used for startup scripts such as jboss which do not background themselves or are relaying the signals to the process they've started PARAMETERS=$@ exec "$PARAMETERS" & # we want to find out what the exit code is PID=$! wait $PID
Because of the fact that agent is not able to run processes in background, when running agent in an interactive mode and sending the SIGINT (CTRL+C), it consequently kills all the processes run by the agent e.g. AS7 in case it was (re)started by agent's operation.
AS use the trap command in their launch script relaying all the signals coming to the process of the script to the process of the server.
To overcome this problem we have to provide a way to invoke an external process in the background. In linux world, this is done by appending the ampersand character. Unfortunately, we can't use this feature directly for the Java runtime.exec() framework, because it passes the ampersand as a common parameter to the command. (I.e. it work only for shell scripts, where the ampersand is correctly interpreted).
What we can do is to provide a launch shell script with simple content running everything what it gets as a parameter in the background.
#!/bin/sh # used for startup scripts such as jboss which do not background themselves or are relaying the signals to the process they've started PARAMETERS=$@ exec "$PARAMETERS" & # we want to find out what the exit code is PID=$! wait $PID
It would be nice to allow users for modifying those scripts or provide their own. For instance, one may want to run certain services as a certain user. It is pretty common use case and right now, we don't support it. If an arbitrary script could be provided for running the actual commands, there is nothing easier than adding sudo -u johndoe $@ to their script.
To allow it, each plugin has to have its own bin directory (in addition to its own data dir and tmp dir). $RHQ_AGENT_HOME/data/plugin/bin can be the default directory the user scripts. So the granularity would be bin directory per plugin. This is not DRY so we can go further and "deploy" the predefined user scripts located in $RHQ_AGENT_HOME/bin/plugin-scripts directory into each discovered plugin's bin directory. Doing that, there will be only one location where users have to put their customized script and we will copy it to all plugin bin directories for them.
I've started some prototyping in my forked repo on GitHub.
For scanning the $RHQ_AGENT_HOME/bin/plugin-scripts location the WatchService can be used. If we want to stay Java 6 compliant, there is an alternative in apache-vfs.
Here is an example code snippet doing the job http://stackoverflow.com/a/7977428/1594980.
The registration of a new listener for each plugin can be done in InventoryManager.initResourceContainer(). To me, it logically fits here.
Don't worry about hot-deploying scripts here. We don't need to worry about implementing directory polling or more sophisticated directory watching. In fact, I would say this would be more of a security issue than anything (we want to avoid any way of some hacking coming in and changing the scripts a running agent is going to use). Instead, the plugin container should just, at startup, find the core scripts and use those when building the plugins' bin directories (which happens only at startup). I think there should be a new PluginContainerConfiguration entry for "Core Scripts" or something like that. This way, the agent can pass this information to the PC without the PC worrying about agent directory structure.
Regarding plugin-provided scripts, when the PC deploys a plugin, and it creates the data/<plugin>/bin directory, it is at this time when the PC should just extract out the plugin jar's "bin/" directory - putting all files it finds there in the data/<plugin>/bin directory as well as all files that are in the PC's "core scripts" directory (which comes from the PC's configuration, which is populated by the agentmain during initialization time).