Bug 1052045 - race condition in util.py when creating directories
Summary: race condition in util.py when creating directories
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-13 08:19 UTC by Tuomo Soini
Modified: 2014-04-19 09:19 UTC (History)
3 users (show)

Fixed In Version: mock-1.1.38-1.el6
Clone Of:
Environment:
Last Closed: 2014-04-09 13:18:25 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Fix for race in directory creation (880 bytes, patch)
2014-01-13 08:19 UTC, Tuomo Soini
no flags Details | Diff

Description Tuomo Soini 2014-01-13 08:19:58 UTC
Created attachment 849177 [details]
Fix for race in directory creation

Description of problem:

Tested with mock-1.1.35.

When starting several instances of mock at the same time and root_cache plugin is used and /var/cache/mock is empty there is a reace condition and only first mock runs successful and other fails with:

ERROR: Could not create dir /var/cache/mock/fedora-20-i386/root_cache/. Error: [Errno 17] File exists: '/var/cache/mock/fedora-20-i386/root_cache/'
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 69, in mkdirIfAbsent
    os.makedirs(dirName)
  File "/usr/lib64/python2.6/os.py", line 157, in makedirs
    mkdir(name, mode)

mkdirIfAbsent doesn't catch situation where directory is created by other instance.

Comment 1 Clark Williams 2014-02-06 23:16:01 UTC
I'm presuming that you are specifying different chroot directories for each instance of mock using the --uniqueext option, otherwise you'd have chroot collisions. 

You're hitting a race condition where multiple mock instances want to use a non-existent cache. The first instance to get there starts building the cache and the others fail because they think they need to create the cache and start down that path, but got beaten to the start of the code. It looks like I need to lock earlier in the code, wait for a lock, then realize that the cache has already been built by a previous locker and just use the cache. 

Let me see if I can do something that doesn't require tons of code.

Comment 2 Clark Williams 2014-02-06 23:33:31 UTC
Sigh. I went in and coded up a fix, went to attach it so you could look at it and realized you had already done the same thing.  The only difference is that I looked for errno.EEXIST and did a 'pass' at that point and you just looked for != errno.EEXIST.

I'll apply your patch for the next release.

Comment 3 Tuomo Soini 2014-02-07 08:54:34 UTC
Exactly. You only hit this problem if you have software starting mock builds. You never hit this if you run mock manually because you can't start several mock instances at exactly same time.

Comment 4 Fedora Update System 2014-03-25 20:24:32 UTC
mock-1.1.37-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mock-1.1.37-1.fc19

Comment 5 Fedora Update System 2014-03-25 20:26:58 UTC
mock-1.1.37-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mock-1.1.37-1.fc20

Comment 6 Fedora Update System 2014-03-25 20:29:05 UTC
mock-1.1.37-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.37-1.el6

Comment 7 Fedora Update System 2014-03-26 17:37:50 UTC
Package mock-1.1.37-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mock-1.1.37-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0960/mock-1.1.37-1.el6
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2014-03-27 17:47:37 UTC
mock-1.1.37-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mock-1.1.37-2.fc20

Comment 9 Fedora Update System 2014-03-27 17:49:28 UTC
mock-1.1.37-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mock-1.1.37-2.fc19

Comment 10 Fedora Update System 2014-03-27 17:51:23 UTC
mock-1.1.37-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.37-2.el6

Comment 11 Fedora Update System 2014-03-31 19:04:12 UTC
mock-1.1.38-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mock-1.1.38-1.fc19

Comment 12 Fedora Update System 2014-03-31 19:06:34 UTC
mock-1.1.38-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.38-1.el6

Comment 13 Fedora Update System 2014-03-31 19:08:30 UTC
mock-1.1.38-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mock-1.1.38-1.fc20

Comment 14 Fedora Update System 2014-04-09 13:18:25 UTC
mock-1.1.38-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2014-04-18 15:37:25 UTC
mock-1.1.38-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2014-04-19 09:19:42 UTC
mock-1.1.38-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.


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