the original report on our side w/bunches of tracebacks: http://crbug.com/481223

with that traceback in hand, it's pretty trivial to write a reproduction :).  attached!

i couldn't figure out how to make it work w/out completely execing a new python instance.  i suspect the internals were communicating and thus defeating the race.

the unshare() might need some checks so that it skips on older kernels or ones with pidns support disabled.  but i don't have any such system anymore ;).

if all goes well, it should fail fairly quickly:
$ python3.3 ./test.py 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.3/multiprocessing/__init__.py", line 187, in Event
    return Event()
  File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 293, in __init__
    self._cond = Condition(Lock())
  File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 174, in __init__
    self._wait_semaphore = Semaphore(0)
  File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 84, in __init__
    SemLock.__init__(self, SEMAPHORE, value, SEM_VALUE_MAX)
  File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 48, in __init__
    sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
FileExistsError: [Errno 17] File exists
failed

and doesn't take that long to pass:
$ time python3.4 ./test-issue24303.py 
passed!
real    0m1.715s