Comment 3 for bug 1712463

This definitely looks like a bug in the prlimit stuff to me. The assumption that sys.executable is always going to something that can run the prlimit module definitely isn't always the case. Besides the uwsgi case (which admittedly does some weird things) there is also the case where sys.executable is None.

There should be a more robust way to enforce rate limiting on a subprocess that doesn't involve calling a python module with python -m in a s subprocess. Off the top of my head something like multiprocessing.Process(target=prlimit.main, args=($cmd)) should work and not involve trying to divine the python executable path for every conceivable runtime to manually do that.