Bug 877343

Summary: access to not existent file /var/cache/swift/account.recon
Product: Red Hat OpenStack Reporter: Jaroslav Henner <jhenner>
Component: openstack-swiftAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED ERRATA QA Contact: Martina Kollarova <mkollaro>
Severity: low Docs Contact:
Priority: low    
Version: 2.0 (Folsom)CC: derekh, jhenner, markmc, mrunge, ncredi, zaitcev
Target Milestone: snapshot4Keywords: Triaged
Target Release: 2.1   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: openstack-swift-1.7.4-8.el6ost Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 870409 Environment:
Last Closed: 2013-03-21 19:03:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 870409    
Bug Blocks:    
Attachments:
Description Flags
Candidate fix 1
none
Candidate fix 2
none
Candidate fix 3
none
Candidate fix 4 apevec: review+

Description Jaroslav Henner 2012-11-16 10:01:26 UTC 
+++ This bug was initially created as a clone of Bug #870409 +++

Description of problem:
from /var/log/messages:
Oct 26 12:08:15 rhel6 container-replicator Exception dumping recon cache: #012Traceback (most recent call last):#012  File "/usr/lib/python2.6/site-packages/swift/common/utils.py", line 1284, in dump_recon_cache#012    with lock_file(cache_file, lock_timeout, unlink=False) as cf:#012  File "/usr/lib64/python2.6/contextlib.py", line 16, in __enter__#012    return self.gen.next()#012  File "/usr/lib/python2.6/site-packages/swift/common/utils.py", line 852, in lock_file#012    fd = os.open(filename, flags)#012OSError: [Errno 2] No such file or directory: '/var/cache/swift/container.recon'





Version-Release number of selected component (if applicable):
openstack-swift-1.7.4-2.el6.noarch

How reproducible:
100%
just start openstack-swift-*

I don't know, how harmful this is, it seems the services are working.

In fedora 17, that file also does not exist.
Comment 1 Pete Zaitcev 2012-12-15 06:06:14 UTC 
This is quite mysterious. I have an RHEL 6 box where something created
/var/cache/swift, even set permissions right. I swear I did not create it.
But I cannot find anything scripted in the distro that did. Obviously
it needed root privilege.

Although the symptom is harmless, it is extra noise and we should fix this.
Comment 2 Jaroslav Henner 2013-01-02 09:50:35 UTC 
(In reply to comment #1)
> This is quite mysterious. I have an RHEL 6 box where something created
> /var/cache/swift, even set permissions right. I swear I did not create it.
> But I cannot find anything scripted in the distro that did. Obviously
> it needed root privilege.
> 
> Although the symptom is harmless, it is extra noise and we should fix this.

Did you use the puddles or did you use devstack?
Comment 3 Pete Zaitcev 2013-01-08 19:54:01 UTC 
I think I pulled packages one by one out of releng tree instead of using
puddles as such. Should be same packages.

In any case, I was wrong. Apparently I created those myself and forgot:

[root@kvm-ni zaitcev]# history | grep cache
  788  mkdir /var/cache/swift
  789  chown swift /var/cache/swift
  923  yum install memcached
  924  service memcached start
  976  grep /var/cache /var/log/messages
Comment 4 Pete Zaitcev 2013-01-10 04:06:04 UTC 
Created attachment 676014 [details]
Candidate fix 1
Comment 5 Pete Zaitcev 2013-01-10 04:09:06 UTC 
Created attachment 676015 [details]
Candidate fix 2

Oops, forgot to include the new files. This should do it.
Comment 6 Pete Zaitcev 2013-01-10 04:10:03 UTC 
Sorry, please disregard. It was the fix for the bug 885530.
Comment 7 Pete Zaitcev 2013-01-10 20:46:05 UTC 
Created attachment 676543 [details]
Candidate fix 3

Third time is the charm, hopefuly.
This patch was tested by building locally and installing.
There is no need to set the group, in fact might be a bad idea.
Comment 8 Pete Zaitcev 2013-01-21 17:53:29 UTC 
Comment on attachment 676543 [details]
Candidate fix 3

Asking Alan to review real quick and then I'll put this into dist-git. Still training to follow the proper procedure.
Comment 9 Alan Pevec 2013-02-14 22:36:41 UTC 
Comment on attachment 676543 [details]
Candidate fix 3

Any reason %dir %attr(0755, swift, root) %{_localstatedir}/cache/swift is not in main openstack-swift package instead of multiple ownership in each subpackage?
Each subpackage would get it via dependency on the main openstack-swift package (Requires:         %{name} = %{version}-%{release})

I mean, multiple directory ownership is permitted by packaging guidelines but I don't see the reason here, so adding Matthias for the second opinion.
Comment 10 Pete Zaitcev 2013-02-15 02:03:38 UTC 
I thought the extra directory unnecessary with a "naked" swift, e.g. if
someone only wanted tools. It's a trivial cost, however.
Comment 11 Matthias Runge 2013-02-15 08:12:03 UTC 
(In reply to comment #9)
> Any reason %dir %attr(0755, swift, root) %{_localstatedir}/cache/swift is
> not in main openstack-swift package instead of multiple ownership in each
> subpackage?
> Each subpackage would get it via dependency on the main openstack-swift
> package (Requires:         %{name} = %{version}-%{release})
> 
I think, that's exactly the way to go.

> I mean, multiple directory ownership is permitted by packaging guidelines
> but I don't see the reason here, so adding Matthias for the second opinion.

Yes, you may have multiple packages requiring the same directory. In my experience, that make things unnecessarily complicated and will cause issues. if rpm gets stricter. If you don't like to have the main package owning that dir, you also might introduce a dir-owning package, which is required by all packages requiring access to that dir.
Comment 12 Pete Zaitcev 2013-02-20 16:35:44 UTC 
Created attachment 700131 [details]
Candidate fix 4

This version addresses Mattias' review. Now the main package owns
/var/cache/swift.
Comment 13 Pete Zaitcev 2013-02-20 18:05:29 UTC 
modified in openstack-swift-1.7.4-8
Comment 16 errata-xmlrpc 2013-03-21 19:03:15 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0672.html