Description of problem: Install broker and node functionality onto the same box, restart httpd service, broker service and console service will be stopped. Version-Release number of selected component (if applicable): 1.1.x/2013-01-09.1 httpd-2.2.22-14.ep6.el6.x86_64 openshift-origin-broker-1.0.9-1.el6op.noarch rubygem-openshift-origin-console-1.0.5-1.el6op.noarch openshift-console-0.0.11-1.el6op.noarch How reproducible: Always Steps to Reproduce: 1. Install broker and node packages on the same box. 2. Create app from web console to make sure broker and console are working fine. 3. Log into this box, restart httpd service. 4. Access broker service by accessing broker rest api. 5. Access web console Actual results: Broker and Console backend service is stopped, so web console can not be accessed, and can not create and control any app. Expected results: Broker and Console backend service should be always running when restart httpd service. Additional info:
I just figured out this is being caused by httpd-2.2.22-14.ep6.el6 and httpd-2.2.17-15.4.ep5.el6.x86_64.rpm. The former ships with EAP and the latter comes with EWS. Installing the httpd from RHEL fixed the issue. We should consider taking a few actions: * Blacklisting the httpd from EAP/EWS * Reporting a bug against their httpd build. The initscript is not properly using the pidfile * Adding a check to oo-diagnostics to look for the JBoss httpd
I just created Bug #894955
Also, we should notify GSS of this issue since it is most likely already affecting users.
It's worth noting that this wouldn't happen if the user doesn't have the node and broker on the same machine.
Based on Comment #5 I don't think we need to bother GSS about this. I've also lowered the severity.
It's conceivable they might enable the EAP/EWS repos (just enable everything) on the broker even though not installing node stuff there. I'm not sure under subscription manager that you specify repos at all. Something to consider, good argument for the oo-diagnostics test. Also I think this is new with 2.2.22. Seems like the best course is to file a bug against the JBoss builds.
Also... wouldn't this kill most of the gears on a node?? Fortunately we're doing graceful restarts for config changes...
Yeah, that _is_ scary. I'll try that out.
You're completely right about it killing all the gears that rely on httpd. I'm raising the severity to high for both this bug and the JBoss one. Here are the options we have to work around this: 1) Document that users add 'exclude=httpd* mod_ssl' to the JBoss yum repo configurations 2) Create a yum plugin that does this automatically I don't like either of these options honestly but I'm open to #2 in the longer term since this is going to be a support nightmare. I'm hopeful that the JBoss team will be able to solve this issue quickly.