Message152719
| Author |
themoken |
| Recipients |
themoken |
| Date |
2012年02月06日.04:13:34 |
| SpamBayes Score |
6.243339e-12 |
| Marked as misclassified |
No |
| Message-id |
<1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I've discovered that using either 2.7.2 or 3.2.2 (from Arch) reorganizing gdbm databases leave hanging file descriptors that will cause EAGAIN errors trying to reopen it until the process is killed. For example:
Python 2.7.2 (default, Jan 31 2012, 13:19:49)
[GCC 4.6.2 20120120 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gdbm
>>> o = gdbm.open("test27", "c")
>>> o.reorganize()
>>> o.close()
>>> o = gdbm.open("test27", "w")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
gdbm.error: (11, 'Resource temporarily unavailable')
>>>
By using lsof you can see that after reorganize() test27 has two open file descriptors, and after close() one is still open with no (obvious) way to close it. This happens with freshly created and populated databases and regardless of open mode flags.
I also tested this on 3.2.2 with dbm.gnu and got identical behavior. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年02月06日 04:13:36 | themoken | set | recipients:
+ themoken |
| 2012年02月06日 04:13:36 | themoken | set | messageid: <1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za> |
| 2012年02月06日 04:13:35 | themoken | link | issue13947 messages |
| 2012年02月06日 04:13:34 | themoken | create |
|