公升級salt導致程序kill問題記錄

blog:

伺服器系統為centos6及centos7

伺服器服務程序都是由salt-master操作salt-minion啟動

伺服器從salt-2015.5.11公升級到2018.03.03版本

在公升級的過程中導致在centos7上的一些程序被kill了

# cat salt.sh
#!/bin/bash
cd /root && wget -o /root/bootstrap-salt.sh && bash /root/bootstrap-salt.sh > /tmp/bootstrap-salt.log
cenos6=`cat /etc/redhat-release|grep 6`
if [ ! -n "$cenos6" ];then
systemctl restart salt-minion && echo `ps -ef |grep salt|grep '201'` |cut -d" " -f2|xargs kill -9 {} >/tmp/kill.log
else
/etc/init.d/salt-minion restart && echo `ps -ef |grep salt|grep 'python2.6'` |cut -d" " -f2|xargs kill -9 {} >/tmp/kill.log
fi

我們在不同的伺服器執行了salt.sh之後發現了在centos7上面的一些服務程序被kill了。之後我們排查是否因為這個指令碼導致的問題，經過排查後發現bootstrap-salt.sh執行後是不會導致相關程序被kill

我們懷疑是不是

systemctl restart salt-minion && echo `ps -ef |grep salt|grep '201'` |cut -d" " -f2|xargs kill -9 {} >/tmp/kill.log

導致的問題，另外因為我們的程序在被kill -15的時候會記錄日誌我們從日誌裡發現程序確實是因為kill -15才掛掉的。那我可以認為並不是指令碼裡的kill -9引起的

以上我們認為有可能systemctl restart salt-minion引起的，接下來我們重複的執行這條命令,發現乙個共同的問題就是只有被kill的程序是由salt-minion啟動的時候才會掛掉。如果是由手動啟動的程序不會因為執行這個命令而掛掉。

用starce可以看出程序的系統呼叫執行strace -e signal=sigterm -p 之後重啟salt-minion 發現程序是被systemd乾掉的

--- sigterm  ---

所以這個掛掉的問題應該是salt-minion和systemd之間的問題

研究了一下systemd的原理發現systemctl在restart service的時候，有個killmode引數，預設是control-group，會向控制組內的所有程序傳送sigterm。而salt的服務配置裡就使用的預設引數，由salt-minion啟動的程序都在salt這個組裡，所以會導致相關程序被kill

ps axwf -eo pid,user,cgroup 可以看一下是不是crgoup一樣

因為公升級salt版本 minion重啟的時候會導致由salt啟動的程序掛掉的問題原因是centos7版本程序有systemd來進行管理遠端的master傳送命令給對應系統的minion minion作為父程序啟動相關服務相關服務會copy minion的cgroup作為自己的cgroup 當minion重啟的時候因為killmode引數，預設是control-group,所以systemd會找到和salt-minion一樣的cgroup進行並且讓他們停止執行。所以說導致服務掛掉，解決的辦法是修改/usr/lib/systemd/system/salt-minion.service 增加killmode=process 會解決這個問題

公升級salt導致程序kill問題記錄

Android多程序導致的問題

VS水晶報表公升級問題記錄

165 突破網路質量導致的pip公升級問題

公升級salt導致程序kill問題記錄

Android多程序導致的問題

VS水晶報表公升級問題記錄

165 突破網路質量導致的pip公升級問題

相關推薦