总结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]:~$ |
