Description of problem: I tried to deploy the sample bundle from $RHQ_CHECKOUT/etc/samples/provisioning/sample-bundle using an agent running as root (which is important, because the bundle (as I understand it) should install a new script into /etc/init.d). The deployment goes fine until the point where it tries to stop the newly provisioned AS using the system script the bundle was supposed to install with this error message: java.lang.Exception:Failed to execute the bundle Ant script -> java.lang.RuntimeException:Failed to execute bundle deploy file [/home/metlos/Projects/java/jon/deploy/master/agent/rhq-agent/data/tmp/bundle-versions/10041/ant-bundle-recipe3257724608555492402.xml]. Cause: /home/metlos/Projects/java/jon/deploy/master/agent/rhq-agent/data/tmp/bundle-versions/10041/ant-bundle-recipe3257724608555492402.xml:7: Failed to stop jbossas-petstore system service via command [[/etc/init.d/jbossas-petstore, stop]]. -> org.apache.tools.ant.BuildException:Failed to stop jbossas-petstore system service via command [[/etc/init.d/jbossas-petstore, stop]]. -> java.io.IOException:Cannot run program "/etc/init.d/jbossas-petstore": java.io.IOException: error=2, No such file or directory -> java.io.IOException:java.io.IOException: error=2, No such file or directory Version-Release number of selected component (if applicable): 4.3.0-SNAPSHOT How reproducible: always Steps to Reproduce: 1. Try to deploy the sample bundle Actual results: The above mentioned error message during bundle deployment Expected results: bundle deployed successfully Additional info:
<mazz> lkrejci: what's the operating system ? <mazz> because, that bundle ant task only works on RHEL <-- venkat (~vupparap.redhat.com) has quit (Quit: Leaving) <lkrejci> mazz: F14 <mazz> /** <mazz> * An Ant task that installs a system startup/shutdown service. Currently only Red Hat Linux versions are supported. <mazz> */ <mazz> public class SystemServiceType extends AbstractBundleType { <-- skondkar (~skondkar.redhat.com) has quit (Quit: Leaving) <lkrejci> mazz: ok, that makes sense then... maybe we should improve the error reporting.. <-- spagop (~spagop.redhat.com) has left #jboss-on <mazz> I'm curious <-- imckinle (~imckinle.redhat.com) has quit (Ping timeout: 615 seconds) <mazz> because that SHOULD have spit out an error saying "This is not a Red Hat Linux" <mazz> it looks for redhat specific files <mazz> if (!OS_NAME.equals("Linux") || !REDHAT_RELEASE_FILE.exists()) { <mazz> throw new BuildException("The system-service element is only supported on Red Hat Linux systems."); <mazz> } <mazz> private static final File REDHAT_RELEASE_FILE = new File("/etc/redhat-release"); <lkrejci> mazz: that's present on fedora, too <mazz> really <mazz> ok, that answers that <-> shaun_mtg is now known as shaun <mazz> but I guess it doesn't follow the same init.d structure?? <mazz> this is why I didn't want this task to begin with :) too many OS variables for service install/startup <lkrejci> maybe, i'm not sure... but it shouldn't fail silently - because the error is not that the file is not present, but that we weren't able to install it... --> mshirley (~mshirley.208.176.stl.redhat.com) has joined #jboss-on <asantos> mazz - I'm probably missing a detail here, but what the hell. Doesn't chkconfig abstract all the OS stuff away from services?
Currently, the rhq:system-service task supports not only installing a system service script but also installing system configuration files into /etc/sysconfig. I don't think chkconfig nor any other tool is able to do that in a distro-agnostic way, so manual intervention is still needed for that. Also, the rhq:system-service task can be provided with the run levels and start/stop priorities. For this to work with chkconfig, the task would have to edit the provided files before installing them so that chkconfig finds the configuration it needs directly in the file. So while I also think we should strive for making this task not RHEL specific, there is going to be more work there than just calling chkconfig --add script.path. On the otherhand specializing the java code for every linux flavor out there is not a way forward either.
As far as I can tell, the exact same error occurs on RHEL systems as well.