總結1 ：只管制止利用 killall、pgrep 、ps | xargs kill 的方法
總計2 ：只管利用 pidof 可能 pidof | xargs kill 的組合來取代上面的幾個呼吁
泛泛各人 kill 歷程，大概習慣利用如下的方法
|
1 |
killall bt_uinfo_memcached |
|
1 |
ps -C bt_uinfo_memcached --format='pid' --noheaders | xargs kill |
大部門環境下這個都是可以正常事情的，但我們來看一下下面的這個呼吁
|
|
[email protected]:~ root 8765 23103 0 14:13 pts/2 00:00:00 grep --color=auto bt_uinfo_memcached root 26195 1 0 12:43 ? 00:00:32 ./bt_uinfo_memcached -p 20211 -u root -l 0.0.0.0 -m 3072 -d root 26236 1 0 12:43 ? 00:00:30 ./bt_uinfo_memcached -p 20311 -u root -l 0.0.0.0 -m 3072 -d root 26586 1 1 12:43 ? 00:01:15 ./bt_uinfo_memcached -p 20411 -u root -l 0.0.0.0 -m 3072 -d [email protected]:~ |
|
|
[email protected]:~ bt_uinfo_memcached: no process found [email protected]:~ |
killall 呼吁竟然找不到 bt_uinfo_memcached 歷程? 上面 ps 呼吁是列出來了的 。換 pkill 試試，照舊不可
|
|
[email protected]:~ [email protected]:~ [email protected]:~ root 17723 23103 0 14:19 pts/2 00:00:00 grep --color=auto bt_uinfo_memcached root 26195 1 0 12:43 ? 00:00:36 ./bt_uinfo_memcached -p 20211 -u root -l 0.0.0.0 -m 3072 -d root 26236 1 0 12:43 ? 00:00:34 ./bt_uinfo_memcached -p 20311 -u root -l 0.0.0.0 -m 3072 -d root 26586 1 1 12:43 ? 00:01:22 ./bt_uinfo_memcached -p 20411 -u root -l 0.0.0.0 -m 3072 -d [email protected]:~ |
甚至連 ps 也有問題，當 -C(command) 選項的參數值高出15個字符時，實際上是會匹配到其他的歷程
|
|
[email protected]:~$ ps -C bt_uinfo_memcachecd PID TTY TIME CMD 26195 ? 00:01:44 bt_uinfo_memcac 26236 ? 00:01:41 bt_uinfo_memcac 26586 ? 00:03:23 bt_uinfo_memcac [email protected]:~$ ps -C bt_uinfo_memcachecd123456 PID TTY TIME CMD 26195 ? 00:01:44 bt_uinfo_memcac 26236 ? 00:01:41 bt_uinfo_memcac 26586 ? 00:03:23 bt_uinfo_memcac [email protected]:~$ |
為什么會這樣呢? 通過 strace 呼吁可以找到原因
|
|
[email protected]:~ open("/proc/31713/status", O_RDONLY) = 4 open("/proc/31713/cmdline", O_RDONLY) = 4 open("/proc/31716/status", O_RDONLY) = 4 open("/proc/31716/cmdline", O_RDONLY) = 4 open("/proc/31717/status", O_RDONLY) = 4 open("/proc/31717/cmdline", O_RDONLY) = 4 open("/proc/31720/status", O_RDONLY) = 4 open("/proc/31720/cmdline", O_RDONLY) = 4 open("/proc/31721/status", O_RDONLY) = 4 open("/proc/31721/cmdline", O_RDONLY) = 4 [email protected]:~ |
pkill 呼吁查抄的是 /proc/ 下面的 pid 目次的 cmdline 文件和 status 文件。我們找個中一個 bt_uinfo_memcached 歷程 ( 26195 ) 看一下，
|
|
[email protected]:~ ./bt_uinfo_memcached -p 20211 -u root -l 0.0.0.0 -m 3072 -d [email protected]:~ [email protected]:~ [email protected]:~ Name: bt_uinfo_memcac State: S (sleeping) ..... |
可以看到 cmdline 是記錄完整呼吁行的 (pgrep 默認是部門匹配)，而 status 這個文件內里的 Name
字段的值是 bt_uinfo_memcac 而不是 bt_uinfo_memcached ，也就是被截斷了(15個字符，OS 的限制)
!!!
固然 cmdline 文件內里記錄的呼吁是正確的，但我預計 pgrep 會比擬 cmdline 第一個字段和 status 文件的
Name 字段的值是否溝通，假如差異則跳過，所以固然 cmdline 是對的，，但 pkill 并不殺死該歷程
下面再來看 killall 呼吁的
|
|
[email protected]:~$ strace -e trace=file killall bt_uinfo_memcached 2>&1 | grep open | tail open("/proc/31705/stat", O_RDONLY) = 3 open("/proc/31708/stat", O_RDONLY) = 3 open("/proc/31709/stat", O_RDONLY) = 3 open("/proc/31712/stat", O_RDONLY) = 3 open("/proc/31713/stat", O_RDONLY) = 3 open("/proc/31716/stat", O_RDONLY) = 3 open("/proc/31717/stat", O_RDONLY) = 3 open("/proc/31720/stat", O_RDONLY) = 3 open("/proc/31721/stat", O_RDONLY) = 3 open("/proc/32553/stat", O_RDONLY) = 3 [email protected]:~$ |