This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application
Type: behavior Stage:
Components: macOS Versions: Python 2.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: gregory.p.smith, pitrou, rnk, ronaldoussoren, rosslagerwall
Priority: low Keywords:

Created on 2009-08-29 03:19 by rnk, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit rnk, 2009-08-29 03:19 Test case where a daemon thread prevents exec from working
Messages (6)
msg92054 - (view) Author: Reid Kleckner (rnk) (Python committer) Date: 2009-08-29 03:19
The test case is attached.  On Mac OS X (and presumably FreeBSD, which
has the same behavior) when you try to exec from a process that has any
other threads in it, you get an OSError, "Operation not supported". 
Here's the output on my MacBook:

Traceback (most recent call last):
  File "", line 16, in <module>
  File "", line 13, in main
    os.execl('echo', 'hello world')
line 312, in execl
    execv(file, args)
OSError: [Errno 45] Operation not supported

And on my Linux box:

hello world

Here's a similar bug that OCaml had to deal with:

I think it's reasonable for Python to declare this to be a limitation of
the OS, but considering that the other thread could be a daemon thread
that the user doesn't really care about, I think it would be reasonable
for Python to kill the other threads in the process before execing. 
That's what happens on Linux, anyway.

I ran into this problem while trying to add a persistent background
compilation thread to unladen swallow, and wondered if having any other
threads would trigger the same exception.

It's tempting to just write this off, but I figured it should be
documented or left open as a low priority defect.
msg92057 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-08-29 04:57
The issue with execv seems to be resolved on OSX 10.6, and hence the 
problem will go away by itself in the future.

But until OSX 10.5 and earlier have died of this is a valid issue.

My gut feeling is that I'm -1 on killing all threads in os.execv because 
it is unclear if that is a save thing to do (what if the system starts a 
number of threads in the background, killing one of them might crash your 
application before we get around to killing another one).
msg92058 - (view) Author: Reid Kleckner (rnk) (Python committer) Date: 2009-08-29 05:13
Supposedly this bug also affects FreeBSD, but I can't verify it.  I'd
say the problem isn't going away, at least not for that platform, but I
don't feel like it's worth bending over backwards to deal with it either.

As far as it concerns unladen swallow, we'll bring down our background
thread by another means.  Unfortunately, there's no way to join
pythreads, so I have to add a hack that just retries the execv call if
errno == EOPNOTSUPP with an eventual timeout.
msg92059 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-08-29 07:15
There is no OS level API to kill threads.  Python does not kill threads. 

When you exec, your entire process should be replaced by the OS, threads
shouldn't matter they should simply disappear just as the rest of your
process state does.

This is an OS problem.

Most macosx users will only ever use the python that apple feeds them so
I don't see what point working around this in Python would have given
that snow leopard (10.6) appears to fix this.

Feel free to contribute patches with appropriate autoconf magic and
ifdefs surrounding them if you feel otherwise.
msg125165 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-01-03 13:06
I tested this on FreeBSD 8.1 - it outputs 'hello world'.

I think this should be closed - i think the os.exec* functions should mirror the operating system exec* functions. If the platform has a limitation then so be it.

And it seems like the latest versions of those platforms have overcome this limitation anyway.
msg125171 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-01-03 14:05
Agreed, not a Python bug.
Date User Action Args
2022-04-11 14:56:52adminsetgithub: 51049
2011-01-03 14:05:07pitrousetstatus: open -> closed

nosy: + pitrou
messages: + msg125171

resolution: rejected
2011-01-03 13:06:25rosslagerwallsetnosy: + rosslagerwall
messages: + msg125165
2009-12-08 16:43:05ronaldoussorensetassignee: ronaldoussoren ->
2009-08-29 07:16:09gregory.p.smithsetpriority: low
2009-08-29 07:15:39gregory.p.smithsetnosy: + gregory.p.smith
messages: + msg92059
2009-08-29 05:13:32rnksetmessages: + msg92058
2009-08-29 04:57:52ronaldoussorensetmessages: + msg92057
2009-08-29 03:19:46rnkcreate