Bug 889336 - Glance: glance-manage db_sync as root makes glance-registry not start
Glance: glance-manage db_sync as root makes glance-registry not start
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-glance (Show other bugs)
Unspecified Unspecified
medium Severity medium
: async
: 2.1
Assigned To: John Bresnahan
Yaniv Kaul
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2012-12-20 15:46 EST by Dan Prince
Modified: 2016-09-26 09:27 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-24 19:09:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A patch to the init files. (1.51 KB, text/plain)
2013-04-08 23:28 EDT, John Bresnahan
no flags Details

  None (edit)
Description Dan Prince 2012-12-20 15:46:57 EST
Description of problem:

Running glance-manage db_sync as root before starting glance-registry will make /var/log/glance/registry.log ownership root:root which means that glance-registry won't be able to startup (and won't leave any messages in the log file either).

This can be really confusing for users who try to install Glance manually....

A work around might be to chown this file in the Glance registry init script so that we always know the glance user can write to it.
Comment 2 Eoghan Glynn 2012-12-21 11:10:11 EST
Yes, seems like we could use a ExecStartPre= directive in:


to chmod the log if necessary.
Comment 3 John Bresnahan 2013-03-11 14:45:57 EDT
To chmod/chown the file on start up we would have to figure out where the log file is.  We cannot really assume that the file is in /var/log/glance because the user could have changed the location in various ways.

Perhaps the solution here is to just have a friendly log message.
Comment 4 John Bresnahan 2013-03-11 18:45:05 EDT
The RHOS product instructions do not have a user run glance-manage db_sync.  If a user is doing this they are either misguided or doing something more complicated.  If it is the latter then it is fair to assume that they may have modified the configuration files and thus maybe logging some place besides the default location.  Therefore simply changing the ownership of the default file is only a partial solution.

In order to truly solve this we would need one of two things:

1) a utility that tracked down all of the files to which the services were going to write, and correct their permissions where possible.

2) a means to capture stderr from the init scripts and report it to the user.  Right now that output is just directed to /dev/null
Comment 5 John Bresnahan 2013-04-08 23:28:13 EDT
Created attachment 732948 [details]
A patch to the init files.
Comment 6 Pádraig Brady 2013-04-11 19:21:46 EDT
Comment on attachment 732948 [details]
A patch to the init files.

not sure about this.
The issue isn't specific to glance.
Also this doesn't handle the Fedora side of things.
Also the user shouldn't be running db sync as root.
Also this doesn't handle different logging locatations.

Maybe an upstream oslo patch to logging to move unwriteable files
out of the way would be better, and would fix it everywhere.

Isn't the error message for this edge case fairly obvious?
I never wasted any time with this issue at least,
but maybe the error message could be improved.

Comment 7 John Bresnahan 2013-04-24 19:09:44 EDT
Because the user should not run db_sync as root I think this should be a WONT_FIX.  We cannot effectively prevent misuse with root level access.

Note You need to log in before you can comment on or make changes to this bug.