起因
前几天使用 salt ‘*’ test.ping 的时候发现响应内容中有一些“某某minion was already deleted from tracker, probably a duplicate key“的提示信息。刚开始误以为是salt-key管理有问题，尝试删除再重新accept，但是依然会出错。到该minion上检查，发现上面运行了两套salt-minion*三层进程树，一共6个进程，其中一套的PPID为1，另一套的Parent是supervisord。
然后就开始研究这种情况是怎么产生的，发现有两种可能：
第一种可能
supervisor本身不被systemd监管，被SIGKILL信号杀死时，因为SIGKILL由内核直接处理，所以并没有机会关闭下属的进程，导致下属salt-minion进程树泄漏。而且不但salt-minion进程树泄漏，连同样被supervisor监管的另一个服务也一并泄漏，二者的PPID都变成了1号。
不过，如果supervisor本身被systemd监管，在其主进程被杀死时，systemd会给整个service slice cgroup里所有进程补刀，所以并不会泄漏进程；如果supervisor是被SIGTERM信号杀死，它也会给下属子进程发信号，一般也不会泄漏进程。
第二种可能
supervisor没有受到影响，正常运行；supervisor监管的salt-minion三层进程树的其中最高层进程（也就是supervisord的直属子进程）被SIGKILL信号杀死，随即，第二层进程exit(1) （不明原因，可能需要看一下salt-minion源码），导致第三层进程变成孤儿。经检查源代码的_spawn_as_child()函数，supervisor针对其监管下的每一个服务，都是采用 fork() setpgid() execve() 的方式来启动的，在调用setpgid()改变了process group id之后，第三层进程的孤儿收养关系就不再归属于supervisord进程，而是归属于1号进程。
随后supervisor会重启salt-minion服务，产生新的3个进程，加上之前剩下的，一共4个。
结论
- 考虑到观察到6个进程而不是4个，实际发生的大概是前一种情况
- supervisor虽然有“能力”处理进程退出之后马上重启的工作，但是因为使用了setpgid()把下属服务与自己隔离，没使用cgroup机制把下属服务单独圈起来，又不具备1号的神圣地位，其实它并不知道到底下属了多少、哪些进程，从机制原理上就根本无法保证所有下属的孤儿进程都被其reap。还是建议不要在严肃场合使用
- 1号进程神圣，所有的服务进程监管工作都应该交给1号进程来处理
