I'm writing a unittesting framework for servers that uses popen to basically execute "python myserver.py" with shell=False, run some tests, and then proceed to take the server down by killpg. 
This myserver.py can and will use multiprocessing to spawn subprocesses of its own. The problem is, from my tests, it seems that the pgrp pid of the server processes shares the same group pid as the actual main thread running the unittests, therefore doing an os.killpg on the group pid will not only take down the server but also the process calling the popen (not what I want to do). Why does it do this? And how can I make them be on separate group pids that I can kill independently?
You're asking about something pretty messy here. I suspect that none of this is what you want to do at all, and that you really want to accomplish this some simpler way. However, presuming you really want to mess with process groups...
Generally, a new process group is created only by the setpgrp(2) system call. Otherwise, processes created by fork(2) are always members of the current process group. That said, upon creating a new process group, the processes in that group aren't even controlled by any tty and doing what you appear to want to do properly requires understanding the whole process group model. A good reference for how all this works is Stevens, "Advanced Programming in the Unix Environment", which goes into it in gory detail.
If you really want to go down this route, you're going to have to implement popen or the equivalent yourself with all the appropriate system calls made.
Popen-ing a python call that invokes a script using multiprocessing (pgrp issue)?