Description of problem: The Websocket server role, which is intended to facilitate "starting/stopping websocket workers required for proxying remote consoles" (as per http://talk.manageiq.org/t/websocket-server-role/1472 ) disables the UI, the SSUI, and the REST API, making it quite difficult to re-enable. Version-Release number of selected component (if applicable): 5.6.0.8-rc1.20160524155303_f2a5a50 How reproducible: 100% Steps to Reproduce: 1. disable the websocket role. 2. restart the server (at least until https://bugzilla.redhat.com/show_bug.cgi?id=1339702 is fixed) Actual results: The UI, SSUI, and REST API are all disabled. If you run a rake evm:status you will see that the user_interface and the webservices roles are still enabled (assuming they were before), but the UI, SSUI, and REST API are not accessible. Expected results: the intended function of the websocket server role. Additional info: This is probably something to look into, because if someone does turn this role off and restart the server, getting the UI back could potentially be a pretty daunting task depending on the skill level of the user. There is probably a better way, but the only way that seemed to work in this case was to enter the rails console on the server in question and execute MiqServer.my_server.role= MiqServer.my_server.role + ",websocket"
> If you run a rake evm:status you will see that the user_interface and the webservices roles are still enabled (assuming they were before), but the UI, SSUI, and REST API are not accessible. Can you explain what that means? Does rake evm:status show the UI and Webservice workers running after you disable the role? If they're running but you can't access the UI from your browser, can you check your httpd(apache) logs?
If you disable websocket, the UI and webservices roles are functionally disabled, in other words, you can't access the UI, SSUI, or REST API. When you run rake:evm status, it gives a list of enabled roles: (e.g. automate:database_owner:reporting:user_interface:web_services ). The roles are still "enabled" in this sense, but they don't work. If you disable the websocket role it seems to disable apache entirely. Trying to turn it on manually fails.
> If you disable the websocket role it seems to disable apache entirely. Trying to turn it on manually fails. Can you provide more details? What fails? what's the error? What do the apache logs show?
Joe, If you: 1) uncheck the websocket role in the UI and leave the webservices and user_interface roles checked. 2) restart evmserverd (at least until this bug is fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1339702 When evmserverd comes back up, apache is not started. Checking the status returns: [root@cfme41 vmdb]# systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since tor 2016-06-02 05:51:51 EDT; 15min ago Docs: man:httpd(8) man:apachectl(8) Process: 14259 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE) Process: 14257 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE) Main PID: 14257 (code=exited, status=1/FAILURE) jun 02 05:51:51 cfme41 systemd[1]: Starting The Apache HTTP Server... jun 02 05:51:51 cfme41 httpd[14257]: [Thu Jun 02 05:51:51.642211 2016] [so:warn] [pid 14257] AH01574: module ssl_module is already loaded, skipping jun 02 05:51:51 cfme41 httpd[14257]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message jun 02 05:51:51 cfme41 systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE jun 02 05:51:51 cfme41 kill[14259]: kill: cannot find process "" jun 02 05:51:51 cfme41 systemd[1]: httpd.service: control process exited, code=exited status=1 jun 02 05:51:51 cfme41 systemd[1]: Failed to start The Apache HTTP Server. jun 02 05:51:51 cfme41 systemd[1]: Unit httpd.service entered failed state. jun 02 05:51:51 cfme41 systemd[1]: httpd.service failed. and as expected, trying to start it manually returns: [root@cfme41 vmdb]# systemctl start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. There aren't any errors (or anything interesting) in the vmdb/log/apache directory or in the /var/log/httpd directory, probably because apache never gets started to log any errors after evmserverd restarts. Obviously, with apache down, one can not access the UI, SSUI, or REST API, even though those roles were left as enabled in the UI. Let me know if this description is more helpful, and if it's not, let's set up a quick call.
This bug: https://bugzilla.redhat.com/show_bug.cgi?id=1341290 Is a little more descriptive of the restart issue (marked as a duplicate of 1339702, mentioned above.)
Hi Krain, This looks suspicious: jun 02 05:51:51 cfme41 httpd[14257]: [Thu Jun 02 05:51:51.642211 2016] [so:warn] [pid 14257] AH01574: module ssl_module is already loaded, skipping Is it possible you an issue with the ssl configuration? see: https://www.centos.org/forums/viewtopic.php?t=48867 'Using above command, it was identified that SSL.conf file has been included twice in httpd.conf.' Maybe you can try changing the apache log level in httpd.conf and recreate the issue to see more information.
It's not clear to me what additional information is necessary here. If you turn off the websocket role, it disables the UI and the REST API. There were no modifications made to the Apache config. If that's not the intended result, or if you are not able to recreate the bug, please let me know and we can have a call.
Thanks Krain, we've found it's a duplicate of bug 1337525 in which we're not letting apache gracefully shutdown. *** This bug has been marked as a duplicate of bug 1337525 ***