Bug 868966 - swift-proxy-server fails to start due to missing /var/lib/swift
Summary: swift-proxy-server fails to start due to missing /var/lib/swift
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: openstack-swift
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Derek Higgins
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-22 15:16 UTC by Steven Hardy
Modified: 2012-11-28 16:26 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-28 16:26:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Steven Hardy 2012-10-22 15:16:53 UTC
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
openstack-swift-object-1.7.4-1.fc18.noarch
openstack-swift-account-1.7.4-1.fc18.noarch
openstack-swift-plugin-swift3-1.0.0-0.20120613git.fc18.noarch
openstack-swift-1.7.4-1.fc18.noarch
python-swiftclient-1.2.0-3.fc18.noarch
openstack-swift-proxy-1.7.4-1.fc18.noarch
openstack-swift-container-1.7.4-1.fc18.noarch

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:
http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17

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 15:04:01 UTC
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 15:06:52 UTC
(In reply to comment #1)
> e.g.
> signing_dirname = /tmp/keystone-signing-swift

sorry,
signing_dir = /tmp/keystone-signing-swift

Comment 3 Derek Higgins 2012-11-07 10:10:17 UTC
Stephen the default proxy config that now comes with swift contains 

[filter:authtoken]
...
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 11:23:29 UTC
Hi Derek, Alan,

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

http://fedoraproject.org/wiki/Features/tmp-on-tmpfs

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 12:25:51 UTC
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

Comment 6 Steven Hardy 2012-11-07 12:58:17 UTC
(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 16:26:44 UTC
Closing, not a bug, details in comments


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