Bug 1417171

Summary: MiqUiWorker fails to start
Product: Red Hat CloudForms Management Engine Reporter: ncatling
Component: ApplianceAssignee: Nick Carboni <ncarboni>
Status: CLOSED CURRENTRELEASE QA Contact: luke couzens <lcouzens>
Severity: high Docs Contact:
Priority: high    
Version: 5.7.0CC: abellott, cbolz, jhardy, lavenel, lcouzens, ncarboni, obarenbo, sacpatil, simaishi, vestival
Target Milestone: GAKeywords: TestOnly, ZStream
Target Release: 5.8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: worker
Fixed In Version: 5.8.0.2 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1425873 (view as bug list) Environment:
Last Closed: 2017-06-12 17:32:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1425873    

Description ncatling 2017-01-27 12:08:32 UTC
Description of problem:
Upon EVM restart, MiqUiWorker and associated processes (MiqWebServiceWorker, MiqWebsocketWorker) fail to start.

No errors reported in the logs and appliance UI no longer accessible. No discernible configuration changes made prior to this behaviour.

This has occurred twice, with freshly installed appliances.


Version-Release number of selected component (if applicable):
VMware appliance version 5.7.0.17.


How reproducible:

Steps to Reproduce:
1. Import example database (to be provided).
2.
3.

Actual results:


Expected results:


Additional info:

Roles are enabled:

[root@localhost ~]# vmdb
[root@localhost vmdb]# rails c
irb(main):001:0> MiqServer.my_server.assigned_role_names
PostgreSQLAdapter#log_after_checkout, connection_pool: size: 5, connections: 1, in use: 1, waiting_in_queue: 0
=> ["automate", "database_operations", "database_owner", "ems_inventory", "ems_operations", "event", "reporting", "scheduler", "smartstate", "user_interface", "web_services", "websocket"]

Comment 5 Nick Carboni 2017-02-20 19:18:07 UTC
This should be fixed by https://github.com/ManageIQ/manageiq/pull/13976 which allows the server to continue on to monitoring other worker classes even if one raises an error.

The underlying issue is described here https://github.com/ManageIQ/manageiq/issues/13958

Comment 7 luke couzens 2017-05-03 14:57:02 UTC
Verified in 5.8.0.13