Created attachment 744217 [details] rhq_server_status_install_start Description of problem: RHQ Control - rhqctl.bat cannot install/stop/start server after rhq-server service removal Version-Release number of selected component (if applicable): jenkins buils 198 How reproducible: 2 of 2 Steps to Reproduce: 1. rhqctl.bat install 2. rhqctl.bat stop 3. rhq-server remove 4. rhqctl.bat status --server 5. rhqctl.bat install --server 6. rhqctl.bat start --server Actual results: after step4. server is not installed message present after step5. server installed message present after step6. server is not installed message present Expected results: after step4. server is not installed message present after step5. server installation starts (starts at the end rhq server) after step6. server is running Additional info: screenshot attached
This may be a "works as expected", I'm not sure. Basically, we're a victim of terminology here. 'Rhqctl install' is used to install *the RHQ product*. On Windows, that also means it installs Windows services for storage/server/agent. If, after installing the product, the user removes a windows service via the component-specific bat file (e.g. 'rhq-server,bat remove') then the windows service will be gone. But, in this scenario the server is *still installed* and could be run in console mode. Note that we don't [currently] offer a 'rhqctl remove' option specifically because we don't really encourage the windows service removal (and it does not even apply to linux). There really isn't a reason to remove the services unless your are trying to wipe RHQ from your system completely. So, basically, 'rhqctl install --server' is working as expected, it is telling you that in fact the server is installed, which it is. My inclination is to say that if you remove the service via the component-specific bat file, you should add it back the same way, if necessary (e.g. 'rhq-server.bat install'). Alternatively, we could I suppose always try to install the windows services in response to 'rhqctl install', but this would make the code more complicated and perhaps make things less clear semantically. So, as it stands, I guess I'd vote to leave it as-is. If triaged to make a change, please make clear what the desired behavior would be.
Thanks Jay. Having your explanation I would go with current implementation and mark bug as won't fix, cause the scenario is "not supported".