Bug 868966 - swift-proxy-server fails to start due to missing /var/lib/swift
swift-proxy-server fails to start due to missing /var/lib/swift
Product: Fedora
Classification: Fedora
Component: openstack-swift (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Derek Higgins
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-10-22 11:16 EDT by Steven Hardy
Modified: 2012-11-28 11:26 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-28 11:26:44 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steven Hardy 2012-10-22 11:16:53 EDT
Description of problem:

Trying to start swift-proxy-server results in error due to missing /var/lib/swift directory

Version-Release number of selected component (if applicable):

# rpm -qa | grep swift

I have the http://repos.fedorapeople.org/repos/openstack/openstack-folsom repo enabled, F18 alpha, with updates-testing enabled, all up-to-date

How reproducible:

Always, until worked around by manually creating the missing directory

Steps to Reproduce:
I was following the F17 steps to create a minimal swift setup:

This step succeeds, but there are errors in the logs:

for srv in account container object proxy  ; do sudo service openstack-swift-$srv start ; done
Actual results:

Oct 22 16:54:04 heattestlt swift-proxy-server[8258]: os.makedirs(self.signing_dirname)
Oct 22 16:54:04 heattestlt swift-proxy-server[8258]: File "/usr/lib64/python2.7/os.py", line 150, in makedirs
Oct 22 16:54:04 heattestlt swift-proxy-server[8258]: makedirs(head, mode)
Oct 22 16:54:04 heattestlt swift-proxy-server[8258]: File "/usr/lib64/python2.7/os.py", line 157, in makedirs
Oct 22 16:54:04 heattestlt swift-proxy-server[8258]: mkdir(name, mode)
Oct 22 16:54:04 heattestlt swift-proxy-server[8258]: OSError: [Errno 13] Permission denied: '/var/lib/swift'
Oct 22 16:54:04 heattestlt systemd[1]: openstack-swift-proxy.service: main process exited, code=exited, status=1
Oct 22 16:54:05 heattestlt systemd[1]: Unit openstack-swift-proxy.service entered failed state.

Expected results:

No error, the directory should probably be created by the openstack-swift-proxy package I guess.

Additional info:

Woraround is simple:
mkdir /var/lib/swift
chown swift:swift /var/lib/swift
Comment 1 Alan Pevec 2012-10-24 11:04:01 EDT
That's authtoken middleware trying to create $HOME/keystone-signing
(default for middleware signing_dir parameter)
Swift itself doesn't use homedir.

You can specify different value in proxy-server.conf [filter:authtoken] section e.g.
signing_dirname = /tmp/keystone-signing-swift
Comment 2 Alan Pevec 2012-10-24 11:06:52 EDT
(In reply to comment #1)
> e.g.
> signing_dirname = /tmp/keystone-signing-swift

signing_dir = /tmp/keystone-signing-swift
Comment 3 Derek Higgins 2012-11-07 05:10:17 EST
Stephen the default proxy config that now comes with swift contains 

signing_dir = /tmp/keystone-signing-swift

if you were following the F17 instructions then you would have removed signing_dir

if this is the case I think this can be closed, can you confirm this?
Comment 4 Steven Hardy 2012-11-07 06:23:29 EST
Hi Derek, Alan,

So the problem is /tmp doesn't persist across reboot in F18:


So you probably need to point at /var/tmp or this will break everytime the user reboots, unless there's something in the service start script which creates the directory?

Sorry, I don't have my F18 system on-hand to test, but I can do further investigation next week if required.
Comment 5 Alan Pevec 2012-11-07 07:25:51 EST
Reboot shouldn't break it, signing_dir is created when middleware starts:
Comment 6 Steven Hardy 2012-11-07 07:58:17 EST
(In reply to comment #5)
> Reboot shouldn't break it, signing_dir is created when middleware starts:
> https://github.com/openstack/keystone/blob/stable/folsom/keystone/middleware/
> auth_token.py#L207

Ah, OK, great, sounds like this can be closed then, I'll re-test next week, thanks!
Comment 7 Derek Higgins 2012-11-28 11:26:44 EST
Closing, not a bug, details in comments

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