classification
Title: open() does not able to set flags, such as O_CLOEXEC
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: duplicate
Dependencies: Superseder: io.FileIO and io.open should support openat
View: 12797
Assigned To: neologix Nosy List: alexey-smirnov, amaury.forgeotdarc, georg.brandl, haypo, mmarkk, neologix, petri.lehtinen, pitrou, python-dev, sbt
Priority: normal Keywords: patch

Created on 2011-05-18 19:11 by mmarkk, last changed 2013-01-03 15:24 by haypo. This issue is now closed.

Files
File name Uploaded Description Edit
os_cloexec.diff neologix, 2011-05-19 18:38 patch adding O_CLOEXEC to os module review
os_cloexec_1.diff neologix, 2011-05-19 20:34 review
open_cloexec.py haypo, 2011-05-23 11:50
Messages (49)
msg136259 - (view) Author: Марк Коренберг (mmarkk) Date: 2011-05-18 19:11
In Python3 I'm not able to use open('xxx', 're') as it does not call fopen() anymore. What about extra flags like 'e'=O_CLOEXEC?

P.S.
see issue12103 for list of needed flags

P.P.S
does 2to3 tool properly detect such cases?
msg136261 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-05-18 20:57
These "needed" flags are actually nonstandard extensions of the libc fopen() function on some platforms.

In python3, one can still use fcntl(f.fileno(), FD_SET, FD_CLOEXEC), but a "flags" parameter would be more convenient.
msg136264 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-18 21:53
> In python3, one can still use fcntl(f.fileno(), FD_SET, FD_CLOEXEC)

Note that it's not atomic.
msg136327 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-19 18:38
Here's a patch adding O_CLOEXEC to the os module, with test. This patch makes it possible to open and set a FD CLOEXEC atomically.
O_CLOEXEC is part of POSIX.1-2008, supported by the Linux kernel since 2.6.23 and has been committed recently to FreeBSD.
Note that I'm not sure that adding this flag to built-in open() is necessarily a good idea, because it's not portable and low-level.
The same functionality can be more or less achieved with:
f = os.fdopen(os.open('/etc/fstab', os.O_RDONLY|os.O_CLOEXEC))
msg136328 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-19 19:15
Using spawn_python() to check that os.O_CLOEXEC flag is correctly set seems overkill. Why not just testing fcntl.fcntl(f.fileno(), fcntl.F_GETFL) & FD_CLOEXEC)? I don't think that there are OSes with O_CLOEXEC but without fcntl(F_GETFL).

> Note that I'm not sure that adding this flag to built-in open()
> is necessarily a good idea

I agree.

open() documentation may explain the os.fdopen(os.open()) "trick" to use low-level options like O_SYNC or O_CLOEXEC.
msg136329 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-05-19 19:18
+1 for the patch!
Note that fdopen is now a simple call to open(), so theses lines are equivalent:

python2.7:   open(filename, 're')
python3.3:   open(os.open(filename, os.O_RDONLY|os.O_CLOEXEC))
msg136333 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-19 20:34
> Using spawn_python() to check that os.O_CLOEXEC flag is correctly set seems
> overkill. Why not just testing fcntl.fcntl(f.fileno(), fcntl.F_GETFL) &
> FD_CLOEXEC)?

Because I couldn't find a place where the CLOEXEC flag was fully
tested (I mean, checking in the child process that the FD was
correctly closed), so I took the opportunity to test it thoroughly
here.
But you're right it's maybe a little bit overkill, so here's a patch
using just F_GETFL. Pick up whichever you like.

>> Note that I'm not sure that adding this flag to built-in open()
>> is necessarily a good idea
>
> I agree.
>

OK.

> open() documentation may explain the os.fdopen(os.open()) "trick" to use
> low-level options like O_SYNC or O_CLOEXEC.
>

Why not, but I leave it to someone more comfortable with documentation
than me :-)
msg136353 - (view) Author: Марк Коренберг (mmarkk) Date: 2011-05-20 04:55
Why not to implement 'e' letter in py3k ?

In systems where O_CLOEXEC is not supported in open(), flag should be set non-atomically using fcntl.

To exclude races (in concurrent threads), this two ops should be done under lock (GIL?)
msg136356 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-20 08:52
> Why not to implement 'e' letter in py3k ?
> 
> In systems where O_CLOEXEC is not supported in open(), flag should be set non-atomically using fcntl.

Having an atomic or non-atomic behaviour depending on the OS is not a
good idea.
msg136358 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-20 09:18
> To exclude races (in concurrent threads), this two ops should be done under lock (GIL?)

That won't work, because open(), like other slow syscalls, is called without the GIL held. Furthermore, it wouldn't be atomic anyway (imagine a fork is done from a C extension without the GIL held).
So we would end up tricking people into using a 'e' flag that, contrarily to GNU fopen(), would not be atomic.
Since the fopen() 'e' flag is only available on platform supporting O_CLOEXEC, you're exactly as portable using the fdopen() trick. And you're sure of what's happening.
msg136525 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-22 13:56
@charles-francois.natali: Your patch is ok, you can commit it into 3.1, 3.2, 3.3. But you may wait after 3.2.1.

@Georg Brandl: Should we wait after Python 3.2.1 for this issue?
msg136527 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-22 14:00
>> open() documentation may explain the os.fdopen(os.open()) "trick"
>> to use low-level options like O_SYNC or O_CLOEXEC.

> Why not, but I leave it to someone more comfortable with 
> documentation than me :-)

Issue #12103 should be fine for this idea.
msg136529 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-22 14:07
Oh, by the way: it would also be nice to add os.O_CLOEXEC to Python 2.7.

For example, tempfile._mkstemp_inner() uses:
            fd = _os.open(file, flags, 0600)
            _set_cloexec(fd) # fcntl(fd, F_SETFD, flags | FD_CLOEXEC)
which is not atomic.
msg136535 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-05-22 15:07
One moment -- adding a new value to the os module looks like a new feature to me.  Is there any convincing reason why this needs to go to 3.2?  (And it most definitely shouldn't go to 3.1.)
msg136537 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-22 15:20
No reason. I think this is definitely 3.3 material.
msg136560 - (view) Author: Roundup Robot (python-dev) Date: 2011-05-22 18:41
New changeset f1c544245eab by Charles-François Natali in branch 'default':
Issue #12105: Add O_CLOEXEC to the os module.
http://hg.python.org/cpython/rev/f1c544245eab
msg136561 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-22 18:45
I've committed the patch to 3.3.
Since the documentation aspect is traced in Issue #12103, I'm closing this issue.
Марк, thanks for reporting this!
msg136562 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-22 19:13
And apparently some buildbot doesn't like it:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/57/

======================================================================
FAIL: test_oscloexec (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_posix.py", line 315, in test_oscloexec
    self.assertTrue(fcntl.fcntl(fd, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
AssertionError: 0 is not true
msg136570 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-22 20:19
> One moment -- adding a new value to the os module looks like a new
> feature to me.  Is there any convincing reason why this needs to go to
> 3.2?  (And it most definitely shouldn't go to 3.1.)

Python doesn't suppose atomic open+CLOEXEC anymore, I consider this as a
regression from Python 2 (which support open("re") with the GNU libc).
Because the patch is simple, I think that it can go in 3.1 and 3.2. Am I
wrong? But... it tooks some years until someone noticed this regression.

Can we add new features to old releases?
msg136572 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-22 20:25
> Python doesn't suppose atomic open+CLOEXEC anymore, I consider this as a
> regression from Python 2 (which support open("re") with the GNU libc).

It has never been documented (nor supported) so, no, I wouldn't consider
it a regression.

> But... it tooks some years until someone noticed this regression.

Which means it's certainly unimportant.

> Can we add new features to old releases?

Well, you already know the answer, don't you? :)
msg136573 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-22 20:37
> And apparently some buildbot doesn't like it

Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1 little-endian

O_CLOEXEC support was added to Linux 2.6.23: this means that the libc defines it while the kernel doesn't support it (it's probably defined as 0).
I could either add some voodoo configure checks to ensure that O_CLOEXEC is indeed supported, or just skip the test on Linux kernels older than 2.6.23. I prefer the later option, it's much simpler and less error-prone. Sure, it will make O_CLOEXEC available while the kernel doesn't support it on some configurations, but since it's a libc issue...
msg136607 - (view) Author: Roundup Robot (python-dev) Date: 2011-05-23 10:54
New changeset bff9265d677d by Victor Stinner in branch 'default':
Issue #12105: test_posix, add the value of O_CLOEXEC in the error message
http://hg.python.org/cpython/rev/bff9265d677d
msg136608 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-23 10:55
> or just skip the test on Linux kernels older than 2.6.23

I like this solution, but I don't know how to test that the kernel doesn't support O_CLOEXEC. My commit bff9265d677d will tell use the value of O_CLOEXEC on the "Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1 little-endian" buildbot.
msg136609 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-23 11:00
> I like this solution, but I don't know how to test that the kernel
> doesn't support O_CLOEXEC. My commit bff9265d677d will tell use the
> value of O_CLOEXEC on the
> "Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1 little-endian" buildbot.

If O_CLOEXEC is a #defined constant in the glibc, it can't be different
from other kernels.
msg136612 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-23 11:19
Story of O_CLOEXEC in the GNU libc, by Ulrich Drepper: "Secure File Descriptor Handling"
http://udrepper.livejournal.com/20407.html

--

> I could either add some voodoo configure checks to ensure
> that O_CLOEXEC is indeed supported

Hum, if I patch tempfile._mkstemp_inner() to use os.O_CLOEXEC if available, whereas this flag has no effect, the function will be less secure on Linux 2.6.22 (if the GNU libc exposes O_CLOEXEC).

Check O_CLOEXEC is configure is not safe if the host compiling Python uses a different kernel that the host running Python (e.g. think of Linux distro: Python is compiled on a different computer).

We need maybe a flag to indicate that O_CLOEXEC is supported by the running kernel or not. Or maybe a function to check it at least?

--

O_CLOEXEC was added to Ruby and then removed because the flag is sometimes ignored:
http://redmine.ruby-lang.org/issues/1291
http://redmine.ruby-lang.org/projects/ruby-19/repository/revisions/31643

"because boron chkbuild test result says, An old linux kernel ignore O_CLOEXEC silently instead of return an error. It may lead to bring new security risk. So, we have to be pending it until finish to implement proper fallback logic."

--

Read also the discussion about O_CLOEXEC on bugs-findutils mailing list:
"it's not a guarantee that the O_CLOEXEC actually had an effect"

Their patch uses :

static int
fd_is_cloexec (int fd)
{
  const int flags = fcntl (fd, F_GETFD);
  return (flags & FD_CLOEXEC) || (fcntl (fd, F_GETFL) & O_CLOEXEC);
}

static bool
o_cloexec_works (void)
{
  bool result = false;
  int fd = open ("/", O_RDONLY|O_CLOEXEC);
  if (fd >= 0)
    {
      result = fd_is_cloexec (fd);
      close (fd);
    }
  return result;
}

--

Oh, there is also SOCK_CLOEXEC, which may be useful for #5715.
msg136615 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-23 11:50
Another idea is to write a best-effort function to open a file with CLOEXEC flag:
 * use O_CLOEXEC if available
 * use fcntl(fd, F_SETFD, flags | FD_CLOEXEC) if O_CLOEXEC is missing or was silently ignored by the kernel (by open)

Attached open_cloexec.py is an implementation.

--

Usage of "CLOEXEC" in the Python standard library:

- subprocess: create pipe. use pipe2() or pipe()+fcntl(FD_CLOEXEC)
- test_socket: create a socket. use SOCK_CLOEXEC. The test is skipped if the kernel is Linux < 2.6.28. It has a nice linux_version() which should be moved to the platform module.
- test_posix: check open(O_CLOEXEC).
- test_tempfile: test "cloexec" behaviour using os.spawnl()
- xmlrpclib: use FD_CLOEXEC on the socket

You may also add pipe_cloexec() to os, and socket_cloexec() to socket?
msg136616 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-23 11:52
> My commit bff9265d677d will tell use the value of O_CLOEXEC on the
> "Linux-2.6.22-vs2.2.0.7-gentoo-..." buildbot.

Here you have:
"AssertionError: 0 is not true : CLOEXEC flag not set (O_CLOEXEC=0x80000)"

It's the same value on my Debian Sid. So we cannot test O_CLOEXEC value, we have to check the kernel version.
msg136618 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-23 12:06
The real issue is that the libc defines O_CLOEXEC, but kernels prior to 2.6.23 don't support it: instead of returning EINVAL, the socket syscall silently ignores the flag (don't know why I made the comment about this flag being defined to 0...).
IMHO this is really a distribution packaging bug (kernel/libc mismatch), and a quite serious one.
I don't think we should be fixing this in Python, but that we should merely skip this test on kernels older than 2.6.23.
People should complain to their distributions vendors instead (I tested this on RHEL4, RHEL6 and Debian Squeeze without problem).

I personally don't like the idea of a best-effort O_CLOEXEC implementation: providing a O_CLOEXEC flag which is not atomic feels really wrong to me.
msg136619 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-23 12:11
> The real issue is that the libc defines O_CLOEXEC, but kernels prior 
> to 2.6.23 don't support it: instead of returning EINVAL, the socket
> syscall silently ignores the flag (don't know why I made the comment
> about this flag being defined to 0...).

This is a kernel bug, not a bug in the GNU libc (ask Ulrich if you are not sure ;-)). An host can have multiple kernel versions (and choose at boot time using GRUB/LILO/...), but it has usually only one C library. You cannot change the version of the libc depending on the kernel.

If you really want to fix this problem, you will have to patch kernel < 2.6.23. Good luck!

Or we can workaround kernel bugs providing a documentation and/or functions for that.
msg136623 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-05-23 12:26
> test_socket: ...has a nice linux_version() which should be moved to 
> the platform module

I created the issue #12158 for that.
msg136624 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-23 12:27
> This is a kernel bug, not a bug in the GNU libc (ask Ulrich if you are not sure ;-)).

Kernels prior to 2.6.23 didn't know about the O_CLOEXEC flag: to catch this kind of problem, every syscall would have to check every bit when it's passed a combination of flags. This would be clumsy, error-prone and slow.
It's not a libc bug either.
The problem is really a distribution issue: using a libc defining a flag unsupported by the kernel is really calling for trouble.

> An host can have multiple kernel versions (and choose at boot time using GRUB/LILO/...)

It's possible, but it's definitely a bad idea, because of such API mismatch. For example nothing prevents a syscall from being removed/modified from one kernel version to another. If your libc doesn't follow, you're up for trouble.
Try using futexes with a kernel not supporting them :-)
msg136696 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-23 21:16
@Victor
Since linux_version() won't be added to the platform module, could you add it to test.support so that it can be used in the O_CLOEXEC test?
msg136707 - (view) Author: Roundup Robot (python-dev) Date: 2011-05-23 22:29
New changeset 9a16fa0c9548 by Victor Stinner in branch 'default':
Issue #12105: test_posix skips test_oscloexec() on Linux < 2.6.23
http://hg.python.org/cpython/rev/9a16fa0c9548
msg136759 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-05-24 16:11
Checking the kernel version did the trick, the test now run fines on the buildbots.
Thanks Victor.
Re-closing.
msg143590 - (view) Author: Марк Коренберг (mmarkk) Date: 2011-09-06 08:42
O_CLOEXEC is not linux-only. Windows has the same flag. In file-opening functions there is lpSecurityAttributes argument. And there is bInheritHandle member of corresponding structure.

http://msdn.microsoft.com/en-us/library/aa379560(v=VS.85).aspx :
bInheritHandle
A Boolean value that specifies whether the returned handle is inherited when a new process is created. If this member is TRUE, the new process inherits the handle.

So, why not to implement 'e' letter in open()? it is true crossplatform. On platforms where inheritance does not work, flag should be ignored.

P.S. Moreover, I think that all file-descriptor-crete functions (open, socket, pipe, dup, ...) should set CLOEXEC atomically
msg143591 - (view) Author: Alexey Smirnov (alexey-smirnov) Date: 2011-09-06 10:09
FreeBSD 8+ also supports O_CLOEXEC in open().
msg143594 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-09-06 11:29
> O_CLOEXEC is not linux-only. Windows has the same flag.
> In file-opening functions there is lpSecurityAttributes argument

How do you suggest to use it? Even on Windows, python calls open(). And lpSecurityAttributes is an argument of CreateFile (which is the win32 kernel function that open() calls)
msg143595 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-09-06 11:37
Windows provides a _get_osfhandle() function. There is not the opposite function? :-)

Anyway, O_CLOEXEC is not available on all platforms. Even on FreeBSD and Linux, it depends on the OS/kernel version.
msg143599 - (view) Author: Марк Коренберг (mmarkk) Date: 2011-09-06 12:29
Some times ago, Python has used fopen() for open() implementation. Now, it uses OS-kernel native function to open files. AFAIK, open() in Windows is a wrapper around CreateFile, created to support some POSIX programs in Windows. Why not to use CreateFile() on Windows platform?
msg143600 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-09-06 12:40
> Why not to use CreateFile() on Windows platform?
Good idea! Please open a separate issue for it.
msg143740 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-09-08 23:05
See also issue #12760 (Add create mode to open).
msg143743 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-09-08 23:22
> > Why not to use CreateFile() on Windows platform?
> Good idea! Please open a separate issue for it.

Done, issue #12939.
msg146757 - (view) Author: Марк Коренберг (mmarkk) Date: 2011-11-01 04:56
Why it is closed as duplicate? nothing said about CLOEXEC in issue12797
msg146760 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-11-01 07:27
> Why it is closed as duplicate? nothing said about CLOEXEC in issue12797

See http://bugs.python.org/issue12760#msg146686
msg146761 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-11-01 08:33
And to be explicit, you can now write:

def open_cloexex(filename, mode='r'):
  return open(filename, mode,
              opener=lambda path, mod: os.open(path, mod|os.O_CLOEXEC))
msg146766 - (view) Author: Марк Коренберг (mmarkk) Date: 2011-11-01 11:55
Well, I understand. So why not to add 'e' (and 'N', which is the same meaning) character, which:

* use O_CLOEXEC in modern Linux
* generate Exception if O_CLOEXEC is not supported (or does not work) on platform. 

Also, implement O_CLOEXEC for open() in Windows using appropriate securityattributes with CreateFile()

?
msg146768 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-11-01 12:07
> So why not to add 'e' character
You said it: because it can't be written consistently on all platforms.
For example, python does not use CreateFile on Windows, see #12939.
msg178942 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-01-03 12:45
Note that on Windows there is an O_NOINHERIT flag which almost corresponds to O_CLOEXEC on Linux.

I don't think there is a need to use the win32 api.
msg178950 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2013-01-03 15:24
> Note that on Windows there is an O_NOINHERIT flag which
> almost corresponds to O_CLOEXEC on Linux.
> I don't think there is a need to use the win32 api.

Ah yes. Because this issue is closed, I created the issue #16850 which is more specific to open + close-and-exec.
History
Date User Action Args
2013-01-03 15:24:48hayposetmessages: + msg178950
2013-01-03 12:45:05sbtsetnosy: + sbt
messages: + msg178942
2011-11-01 12:07:17amaury.forgeotdarcsetmessages: + msg146768
2011-11-01 11:55:57mmarkksetmessages: + msg146766
2011-11-01 08:33:02amaury.forgeotdarcsetmessages: + msg146761
2011-11-01 07:27:44neologixsetmessages: + msg146760
2011-11-01 04:56:31mmarkksetmessages: + msg146757
2011-10-30 21:15:54hayposetresolution: fixed -> duplicate
2011-10-29 15:57:50neologixsetstatus: open -> closed
superseder: io.FileIO and io.open should support openat
2011-09-08 23:22:23hayposetmessages: + msg143743
2011-09-08 23:05:30hayposetmessages: + msg143740
2011-09-06 12:40:47amaury.forgeotdarcsetmessages: + msg143600
2011-09-06 12:29:11mmarkksetmessages: + msg143599
2011-09-06 11:37:40hayposetmessages: + msg143595
2011-09-06 11:29:33amaury.forgeotdarcsetmessages: + msg143594
2011-09-06 10:09:43alexey-smirnovsetmessages: + msg143591
2011-09-06 08:42:54mmarkksetstatus: closed -> open

messages: + msg143590
2011-05-24 16:11:21neologixsetstatus: open -> closed

messages: + msg136759
2011-05-23 22:29:48python-devsetmessages: + msg136707
2011-05-23 21:16:33neologixsetmessages: + msg136696
2011-05-23 12:27:08neologixsetmessages: + msg136624
2011-05-23 12:26:11hayposetmessages: + msg136623
2011-05-23 12:11:27hayposetmessages: + msg136619
2011-05-23 12:06:39neologixsetmessages: + msg136618
2011-05-23 11:52:31hayposetmessages: + msg136616
2011-05-23 11:50:56hayposetfiles: + open_cloexec.py

messages: + msg136615
2011-05-23 11:19:13hayposetmessages: + msg136612
2011-05-23 11:00:54pitrousetmessages: + msg136609
2011-05-23 10:55:46hayposetmessages: + msg136608
2011-05-23 10:54:59python-devsetmessages: + msg136607
2011-05-22 20:37:10neologixsetmessages: + msg136573
2011-05-22 20:25:23pitrousetmessages: + msg136572
2011-05-22 20:19:06hayposetmessages: + msg136570
2011-05-22 19:13:40pitrousetstatus: closed -> open
assignee: neologix
messages: + msg136562
2011-05-22 18:45:09neologixsetstatus: open -> closed
resolution: accepted -> fixed
messages: + msg136561

stage: commit review -> resolved
2011-05-22 18:41:18python-devsetnosy: + python-dev
messages: + msg136560
2011-05-22 15:20:53pitrousetnosy: + pitrou

messages: + msg136537
versions: - Python 3.1, Python 3.2, Python 3.4
2011-05-22 15:07:18georg.brandlsetmessages: + msg136535
2011-05-22 14:07:00hayposetmessages: + msg136529
2011-05-22 14:00:29hayposetmessages: + msg136527
2011-05-22 13:56:40hayposetnosy: + georg.brandl
messages: + msg136525
2011-05-20 09:33:26petri.lehtinensetnosy: + petri.lehtinen
2011-05-20 09:18:10neologixsetmessages: + msg136358
2011-05-20 08:52:25hayposetmessages: + msg136356
2011-05-20 04:55:46mmarkksetmessages: + msg136353
2011-05-19 20:34:19neologixsetfiles: + os_cloexec_1.diff

messages: + msg136333
2011-05-19 19:18:52amaury.forgeotdarcsetresolution: accepted
messages: + msg136329
stage: commit review
2011-05-19 19:15:32hayposetmessages: + msg136328
2011-05-19 18:38:54neologixsetfiles: + os_cloexec.diff

nosy: + haypo
messages: + msg136327

keywords: + patch
2011-05-19 05:53:26alexey-smirnovsetnosy: + alexey-smirnov
2011-05-18 21:53:13neologixsetnosy: + neologix
messages: + msg136264
2011-05-18 20:57:08amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg136261
2011-05-18 19:11:54mmarkksetcomponents: + Library (Lib)
2011-05-18 19:11:28mmarkkcreate