Ask Your Question

at8eqeq3's profile - activity

2017-01-06 22:46:22 -0500 received badge  Student (source)
2016-08-03 12:52:57 -0500 received badge  Famous Question (source)
2016-08-03 12:52:57 -0500 received badge  Notable Question (source)
2015-12-03 12:28:44 -0500 answered a question Nova services on controller are not working due to SQL error

So, the cause was SELinux blocking access to Postgres. I don't know why there was different behavior between interactive and daemon start. The standard procedure with audit2allow put everything on their places.

Thanks to all.

2015-12-03 11:47:06 -0500 commented answer Nova services on controller are not working due to SQL error

Nope, no difference here.

2015-12-03 11:27:24 -0500 received badge  Popular Question (source)
2015-12-03 00:59:25 -0500 commented question Nova services on controller are not working due to SQL error

If you're telling about [database]/connection directive, then it's more than double checked. I've even dropped the DB and user and re-created them back. nova-manage db sync still working. Or it uses some other directive? Also, I've added some more info to question.

2015-12-02 17:00:14 -0500 asked a question Nova services on controller are not working due to SQL error

Hello.

I'm trying to set up Liberty on VMs with CentOS 7. Following the Install Guide, with only exception is Postgres instead of MySQL. Now, I'm stuck with setting up Nova on Controller node. Some services (nova-cert, nova-consoleauth and nova-scheduler) are reporting they can't connect to SQL (actual message in logs is like WARNING oslo_db.sqlalchemy.engines [req-uuiduuid-uuid-uuid-uuid-uuiduuiduuid - - - - -] SQL connection failed. -nn attempts left.).

Obviously, database is working good and accessible, because other services are working, and connection string is correct, because nova-manage db sync works without errors.

During my later research, I found that running, i.e., su -s /bin/sh -c "nova-scheduler" nova in console works fine. According to logs, it can communicate with database. The error reproduced only when it's started as a daemon.

So, tell me, please, where to look for causes?