Ask Your Question
0

nova-cert and nova-scheduler not started after reboot

asked 2015-02-14 10:27:24 -0600

Herr-Herner gravatar image

We have installed OpenStack Juno as a one-node installation on our test system (Ubuntu 14.04). There still seem to be configuration issues, but one strange thing we are confronted with is that after reboot "nova-cert" and "nova-scheduler" are not started. When I start them manually, everything works fine and the VMs get spawned...

Can anybody give me a hint, what could be the source of the problem? "nova-cert.conf" and "nova-scheduler.conf" are located in "/etc/init". The system service are created, but remain in state "not running" until I start them by hand.

edit retag flag offensive close merge delete

Comments

If you look at the corresponding logs, are they failing to start when your system reboots (i.e., are there errors in the logs)? Or are they simply not starting?

larsks gravatar imagelarsks ( 2015-02-14 14:30:50 -0600 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2015-02-16 02:10:56 -0600

Herr-Herner gravatar image

The configuration looks good now... There seems to be a startup ordering problem. I have switched to verbose and debug. This is the content of nova-scheduler.log, the content of nova-cert.log looks nearly the same. It is strange that the log file interrupts suddenly. The database connection is definitely configured correctly. When I start the nova-scheduler and nova-cert by hand. It gets started without any errors.

2015-02-16 09:00:08.776 4681 INFO nova.openstack.common.service [-] Caught SIGTERM, exiting
2015-02-16 09:00:44.129 1446 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db __new__ /usr/lib/python2.7/dist-packages/nova/servicegroup/api.py:65
2015-02-16 09:00:45.469 1446 DEBUG nova.openstack.common.service [-] Full set of CONF: _wait_for_exit_or_signal /usr/lib/python2.7/dist-packages/nova/openstack/common/service.py:167
2015-02-16 09:00:45.481 1446 DEBUG nova.openstack.common.service [-] ******************************************************************************** log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1979
2015-02-16 09:00:45.488 1446 DEBUG nova.openstack.common.service [-] Configuration options gathered from: log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1980
2015-02-16 09:00:45.496 1446 DEBUG nova.openstack.common.service [-] command line args: ['--config-file=/etc/nova/nova.conf'] log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1981
2015-02-16 09:00:45.497 1446 DEBUG nova.openstack.common.service [-] config files: ['/etc/nova/nova.conf'] log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1982
2015-02-16 09:00:45.504 1446 DEBUG nova.openstack.common.service [-] ================================================================================ log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1983
2015-02-16 09:00:45.505 1446 DEBUG nova.openstack.common.service [-] aggregate_image_properties_isolation_namespace = None log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.507 1446 DEBUG nova.openstack.common.service [-] aggregate_image_properties_isolation_separator = . log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.507 1446 DEBUG nova.openstack.common.service [-] allow_instance_snapshots       = True log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.508 1446 DEBUG nova.openstack.common.service [-] allow_migrate_to_same_host     = False log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.512 1446 DEBUG nova.openstack.common.service [-] allow_resize_to_same_host      = False log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.513 1446 DEBUG nova.openstack.common.service [-] amqp_auto_delete               = False log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.514 1446 DEBUG nova.openstack.common.service [-] amqp_durable_queues            = False log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.515 1446 DEBUG nova.openstack.common.service [-] api_paste_config               = /etc/nova/api-paste.ini log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.517 1446 DEBUG nova.openstack.common.service [-] api_rate_limit                 = False log_opt_values /usr/lib/python2.7/dist-packages/oslo/config/cfg.py:1992
2015-02-16 09:00:45.522 1446 DEBUG nova.openstack.common.service [-] auth_strategy                  = keystone log_opt_values /usr/lib/python2 ...
(more)
edit flag offensive delete link more

Comments

If the problems persist you can always make a @reboot in the crontab starting the services when they boot.

Robin Dekens gravatar imageRobin Dekens ( 2015-02-16 02:49:13 -0600 )edit

Is there a way to make sure that MariaDB and RabbitMQ are started before any other OpenStack services? It's an Ubuntu 14.04 and MariaDB and RabbitMQ are not started via upstart. I made an installation described in the manual.

Herr-Herner gravatar imageHerr-Herner ( 2015-02-16 04:09:13 -0600 )edit

I also had this problem with startup order. This solution http://stackblog.net/?p=14 worked fine for me.

isabyr gravatar imageisabyr ( 2015-05-13 13:09:22 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2015-02-14 10:27:24 -0600

Seen: 1,220 times

Last updated: Feb 16 '15