in python: child processes going defunct while others are not, unsure why

Question

edit: the answer was that the os was axing processes because i was consuming all the memory i am spawning enough subprocesses to keep the load average 1:1 with cores, however at some point within the hour, this script could run for days, 3 of the processes go : ``` tipu 14804 0.0 0.0 328776 428 pts/1 Sl 00:20 0:00 python run.py tipu 14808 64.4 24.1 2163796 1848156 pts/1 Rl 00:20 44:41 python run.py tipu 14809 8.2 0.0 0 0 pts/1 Z 00:20 5:43 [python] tipu 14810 60.3 24.3 2180308 1864664 pts/1 Rl 00:20 41:49 python run.py tipu 14811 20.2 0.0 0 0 pts/1 Z 00:20 14:04 [python] tipu 14812 22.0 0.0 0 0 pts/1 Z 00:20 15:18 [python] tipu 15358 0.0 0.0 103292 872 pts/1 S+ 01:30 0:00 grep python ``` i have no idea why this is happening, attached is the master and slave. i can attach the mysql/pg wrappers if needed as well, any suggestions? `slave.py`: ``` from boto.s3.key import Key import multiprocessing import gzip import os from mysql_wrapper import MySQLWrap from…

Accepted Answer

There's not enough information to be sure, but the problem is very likely to be that `Slave.do_work` is raising an unhandled exception. (There are many lines of your code that could do that in various different conditions.)

When you do that, the child process will just exit.

On POSIX systems… well, the full details are a bit complicated, but in the simple case (what you have here), a child process that exits will stick around as a `<defunct>` process until it gets reaped (because the parent either `wait`s on it, or exits). Since your parent code doesn't wait on the children until the queue is finished, that's exactly what happens.

So, there's a simple duct-tape fix:

```
def do_work(self):
    self.log(str(os.getpid()))
    while True:
        try:
            # the rest of your code
        except Exception as e:
            self.log("something appropriate {}".format(e))
            # you may also want to post a reply back to the parent
```

You might also want to break the massive `try` up into different ones, so you can distinguish between all the different stages where things could go wrong (especially if some of them mean you need a reply, and some mean you don't).

However, it looks like what you're attempting to do is duplicate exactly the behavior of `multiprocessing.Pool`, but have missed the bar in a couple places. Which raises the question: why not just use `Pool` in the first place? You could then simplify/optimize things ever further by using one of the `map` family methods. For example, your entire `Master.run` could be reduced to:

```
self.init()
pool = multiprocessing.Pool(Master.SLAVE_COUNT, initializer=slave_setup)
pool.map(slave_job, tables)
pool.join()
```

And this will handle exceptions for you, and allow you to return values/exceptions if you later need that, and let you use the built-in `logging` library instead of trying to build your own, and so on. And it should only take about a dozens lines of minor code changes to `Slave`, and then you're done.

If you want to submit new jobs from within jobs, the easiest way to do this is probably with a `Future`-based API (which turns things around, making the future result the focus and the pool/executor the dumb thing that provides them, instead of making the pool the focus and the result the dumb thing it gives back), but there are multiple ways to do it with `Pool` as well. For example, right now, you're not returning anything from each job, so, you can just return a list of `tables` to execute. Here's a simple example that shows how to do it:

```
import multiprocessing

def foo(x):
    print(x, x**2)
    return list(range(x))

if __name__ == '__main__':
    pool = multiprocessing.Pool(2)
    jobs = [5]
    while jobs:
        jobs, oldjobs = [], jobs
        for job in oldjobs:
            jobs.extend(pool.apply(foo, [job]))
    pool.close()
    pool.join()
```

Obviously you can condense this a bit by replacing the whole loop with, e.g., a list comprehension fed into `itertools.chain`, and you can make it a lot cleaner-looking by passing "a submitter" object to each job and adding to that instead of returning a list of new jobs, and so on. But I wanted to make it as explicit as possible to show how little there is to it.

At any rate, if you think the explicit queue is easier to understand and manage, go for it. Just look at the source for `multiprocessing.worker` and/or `concurrent.futures.ProcessPoolExecutor` to see what you need to do yourself. It's not that hard, but there are enough things you could get wrong (personally, I always forget at least one edge case when I try to do something like this myself) that it's work looking at code that gets it right.

Alternatively, it seems like the only reason you can't use `concurrent.futures.ProcessPoolExecutor` here is that you need to initialize some per-process state (the `boto.s3.key.Key`, `MySqlWrap`, etc.), for what are probably very good caching reasons. (If this involves a web-service query, a database connect, etc., you certainly don't want to do that once per task!) But there are a few different ways around that.

But you can subclass `ProcessPoolExecutor` and override the undocumented function `_adjust_process_count` (see the source for how simple it is) to pass your setup function, and… that's all you have to do.

Or you can mix and match. Wrap the `Future` from `concurrent.futures` around the `AsyncResult` from `multiprocessing`.

in python: child processes going defunct while others are not, unsure why

Solution

Problem