Red Hat Bugzilla – Bug 970278
oo-frontend-connect starts openshift-node-web-proxy with reload, even if the service is shut off
Last modified: 2016-01-31 21:36:24 EST
Description of problem: When the --websocket argument is passed into oo-frontend-connect it will reload the openshift-node-web-proxy service. This is fine in most cases, but there are times where we need to turn that service off, and keep it off. Instead of calling of calling service openshift-node-web-proxy reload we should call condrestart so that if it's turned off, it won't restart the service. Version-Release number of selected component (if applicable): How reproducible: Create an application for any cartridge that passes --websocket when the openshift-node-web-proxy is turned off. It'll start the service. Steps to Reproduce: 1. service openshift-node-web-proxy stop 2. rhc app create app1 jbossews 3. service openshift-node-web-proxy status Actual results: openshift-node-web-proxy is on. Expected results: openshift-node-web-proxy is off. Additional info: The service script already has a condrestart option defined, we can use that.
We should add a "condreload" - restart is quite a bit more expensive than a reload on this service.
Actually, this is a little weirder. As far as I can see the reload portion of the init script should not cause the daemon to start. Will need to examine this further to see what is happening.
I can't reproduce this on the latest devenv with the following commands: 1. service openshift-node-web-proxy stop 2. rhc app create rmtest php-5.3 3. ps -ef |grep node # Shows nothing 4. service openshift-node-web-proxy status # Shows web-proxy is stopped 5. service openshift-node-web-proxy reload # Reports an error 6. service openshift-node-web-proxy status # Still shows web-proxy is stopped. Reading the code, that's exactly how it should behave. Do you have an environment where this is happening I can have a look at? Thanks!
I haven't been able to reproduce this either, v1 or v2. I'm going to follow up with the customer and dig a little deeper.
We were unable to reproduce this issue. Closing.