[devstack] keystone service fails to start after reboot

Bug #1692767 reported by Tao Li
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Invalid
Undecided
Tao Li
devstack
Fix Released
Undecided
Kirill Zaitsev

Bug Description

Enviroment
OS: CentOS7.2

I deployed the devstack environment successfully in CentOS system. After rebooting the CentOS system, the keystone service could not be started. The uwsgi raised exception as follows.

Apr 23 22:38:53 devstack.localdomain systemd[1]: <email address hidden> failed.
Apr 23 22:42:46 devstack.localdomain systemd[1]: Starting Devstack <email address hidden>...
Apr 23 22:42:46 devstack.localdomain <email address hidden>[7242]: [uWSGI] getting INI configuration from /etc/keystone/keystone-uwsgi-public.ini
Apr 23 22:42:46 devstack.localdomain <email address hidden>[7242]: open("./python_plugin.so"): No such file or directory [core/utils.c line 3686]
Apr 23 22:42:46 devstack.localdomain <email address hidden>[7242]: !!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!!
Apr 23 22:42:46 devstack.localdomain <email address hidden>[7242]: *** Starting uWSGI 2.0.15 (64bit) on [Sun Apr 23 22:42:46 2017] ***
Apr 23 22:42:46 devstack.localdomain systemd[1]: <email address hidden>: main process exited, code=exited, status=1/FAILURE
Apr 23 22:42:46 devstack.localdomain systemd[1]: Failed to start Devstack <email address hidden>.
Apr 23 22:42:46 devstack.localdomain systemd[1]: Unit <email address hidden> entered failed state.
Apr 23 22:42:46 devstack.localdomain systemd[1]: <email address hidden> failed.

So i think this is a bug. I tried to create the /var/run/uwsgi directory and chown it stack user. Then it works.
sudo mkdir -p /var/run/uwsgi
sudo chown stack:stack uwsgi

So what do you think that?

Tao Li (eric-litao)
Changed in keystone:
assignee: nobody → Tao Li (eric-litao)
Revision history for this message
Kirill Zaitsev (kzaitsev) wrote :

The correct way to do it would be to add a tmpfiles.d config file, that would create the directory at startup. also it's not about keystone, but about devstack

summary: - Start keystone service failed with uwsgi in devstack
+ [devstack] keystone service fails to start after reboot
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to devstack (master)

Fix proposed to branch: master
Review: https://review.openstack.org/468457

Changed in devstack:
assignee: nobody → Kirill Zaitsev (kzaitsev)
status: New → In Progress
Revision history for this message
Lance Bragstad (lbragstad) wrote :

I agree with comment #2. It would appear that this is something we should be doing in devstack and unrelated to the keystone service.

Changed in keystone:
status: New → Invalid
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to devstack (master)

Reviewed: https://review.openstack.org/468457
Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=d0db62a476e29355ca08db0237295139c8fce4f6
Submitter: Jenkins
Branch: master

commit d0db62a476e29355ca08db0237295139c8fce4f6
Author: Kirill Zaitsev <email address hidden>
Date: Fri May 26 19:02:52 2017 +0300

    Use systemd-tmpfiles to create /var/run/uwsgi

    On ubuntu contents of /var/run do not persist between reboots. Devstack
    uses /var/run/uwsgi as home for wsgi sockets. This means that after
    rebooting the machine services, that rely on uwsgi would fail to start.
    Currently it affects keystone.service and placement-api.service.
    This patch changes delegates directory creation to systemd-tmpfiles,
    which would run on startup.

    Change-Id: I27d168cea93698739ef08ac76c828695a49176c7
    Closes-Bug: #1692767

Changed in devstack:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.