Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1233237
Summary: | [abrt] blueman: Functions.py:285:get_lockfile:OSError: [Errno 17] File exists: '/home/ssabchev/.cache' | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | ssabchew <ssabcew> | ||||||
Component: | blueman | Assignee: | leigh scott <leigh123linux> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 21 | CC: | fedora, fedora, leigh123linux | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Unspecified | ||||||||
URL: | https://retrace.fedoraproject.org/faf/reports/bthash/69f853cc11a8d329cb2791ae213b8573599eb937 | ||||||||
Whiteboard: | abrt_hash:0997be9f398f003956085a1cd72e1961d04a2c59 | ||||||||
Fixed In Version: | blueman-2.0-9.fc22 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2015-06-21 23:03:31 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
ssabchew
2015-06-18 13:56:09 UTC
Created attachment 1040506 [details]
File: backtrace
Created attachment 1040507 [details]
File: environ
Is this reproducible? The relevant code is: cachedir = GLib.get_user_cache_dir() if not os.path.exists(cachedir): os.mkdir(cachedir) Assuming that os.path.exists works as expected and that the directory really existed when os.mkdir got called, this means it got created between the execution of those two line... Yes. Also directory is there, and GLib.get_user_cache_dir show this: In [38]: GLib.get_user_cache_dir() Out[38]: '/home/ssabchev/.cache' Just for clarification: Is the "yes" in comment 4 the answer to the question from comment 3? If so, how to reproduce the problem? [...] Considering that $HOME/.cache is a global directory which may be created by other programs, it's subject to race conditions and would benefit from OSError (errno.EEXIST) exception handling. About clarification: The "yes" is the answer for the question in comment 3. About .cache - it is a symlink to /tmp/${USERNAME}_cache, may be the problem is somewhere else... URL=https://bugzilla.redhat.com/show_bug.cgi?id=1228488 URL=https://bugzilla.redhat.com/show_bug.cgi?id=1229147 The bluetooth service was stopped, and mask, so after starting it - all is OK. (In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #6) > Considering that $HOME/.cache is a global directory which may be created by > other programs, it's subject to race conditions and would benefit from > OSError (errno.EEXIST) exception handling. Thanks, I added that upstream. :) blueman-2.0-9.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/blueman-2.0-9.fc22 blueman-2.0-9.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/blueman-2.0-9.fc20 blueman-2.0-9.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/blueman-2.0-9.fc21 blueman-2.0-9.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. blueman-2.0-9.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. |