话说最近这几天，冷得不行啊QAQ。。。人都冻傻了，早上起床的痛苦T-T，但是革命尚未成功，同志仍需努力~~

2017年12月19日，怎一个冷字了得！早上维护游戏的时候踩了个SaltStack的新坑，记忆中距离上一次踩坑已经是很久很久以前的事情了，久得让人怎样也不愿意想起当时的“苦”不堪言，但又不可以从脑海里磨灭，和同事一起处理的过程，一张这里痛.jpg可以道尽一切。简直就是"携来百侣曾游，忆往昔峥嵘岁月稠"~简单的概括那时候的情形，就是：深夜逻辑思考，二日游玩，逻辑思考，敲黑板，看黑板，等待，pass

回到主线，今天早上遇到的新坑，第一次碰到，很有意思，简单记录一下：

主机系统: CentOS Linux release 7.4.1708 (Core)

salt-minion: salt-minion 2015.5.10 (Lithium)

问题: 通过saltstack部署管理的服务进程默认成为了salt-minion下的组资源进程，一旦salt-minion服务down了，通过saltstack部署的服务也一一down了，QAQ今早主机上面的游戏进程还有其它服务就是这样子down了

处理方法:

在salt-minion的启动文件处添加一行 KillMode=process，然后systemctl daemon-reload; systemctl restart salt-minion即可

分析:

Centos 7里面的systemd启用了Linux内核特性的CGroups(control groups 控制组)，systemd将一个服务进程统一归类到一个组，其组下派生的进程都归类为组内的子进程，并通过CGroups去分配组内各进程使用的CPU时间、内存、网络、磁盘读写等资源。当然，用户自己可以通过CGroups指定一个组里面的进程使用多少CPU时间、内存、网络、硬盘等资源。这次碰到的坑，也正是由于系统的这种机制导致的，例如以下的例子，我们在salt master上面分发一个任务'systemctl status salt-minion'给指定的minion，minion接受到这个任务之后派生一个salt-minion进程执行这个job，执行过程中，systemd讲会将这个子进程分配到salt-minion的进程组里面，如图：

当然，systemctl status salt-minion这种典型的用户进程里面的交互进程，执行完就退出释放系统资源，没有什么问题。但是，换成用户进程里面的守护进程，只要salt-minion主进程一旦收到stop的信号，后果是很严重滴，都会一起stop掉。这次的坑也是这样造成的，因为systemd里面默认的服务进程设定是control-group，如下图解释:

因此，我们需要更改salt-minion的服务启动文件,在Service段里添加KillMode=process即可~

参考资料: