[[!comment format=mdwn username="joey" subject="""comment 1""" date="2015-12-02T16:34:03Z" content=""" This seems to be the same problem discussed here in the context of git-annex and here in the general context of docker being broken . So, it's a docker problem; since docker containers lack any proper init, nothing waits on orphaned processes. While git-annex normally waits on all child processes it starts, if a git-annex process itself exits for some reason (eg an error) while a child process is running, this results in an orphaned process. It is the responsibility of init to wait on such orphaned processes. So, eg systemd-nspawn containers don't have this problem (in addition to their many, many other benefits over docker). And if you're stuck running docker all it takes to solve the problem is to make the top-level process in the container do a `wait()` loop. As is done by eg . It might be possible for git-annex to have a top-level exception handler that waits on any child processes that might be running. However, this seems difficult to arrange; when git-annex was talking to a child process over a handle, the child process may keep running as long as that handle remains open, so the exception handler would block waiting for the child process to exit. This kind of difficulty is probably why unix delegates this job to init in the first place. """]]