重启服务
[root@node5 bin]# service cloudstack-agent status cloudstack-agent (pid 6657) 正在运行... [root@node5 bin]# service cloudstack-agent stop Stopping Cloud Agent: [root@node5 bin]# service cloudstack-agent status cloudstack-agent (pid 6657) 正在运行..
ps ax |grep jsvc.exec 也验证了进程依然存在
眼前一亮的同时，也发现了之前使用restart带来的问题，stop不成功的问题被掩盖了~~~有没有懊恼？ 不过来不及反思，接下来的问题还远不是这么简单......
[root@node5 bin]# kill -9 6655 6657 [root@node5 bin]# kill -9 6655 6657 -bash: kill: (6655) - 没有那个进程 -bash: kill: (6657) - 没有那个进程 [root@node5 bin]# service cloudstack-agent status cloudstack-agent 已死，但 pid 文件仍存 [root@node5 bin]# rm /var/run/cloudstack-agent.pid rm：是否删除普通文件 "/var/run/cloudstack-agent.pid"？y [root@node5 bin]# service cloudstack-agent status cloudstack-agent 已死，但是 subsys 被锁 [root@node5 bin]# service cloudstack-agent start [root@node5 bin]# service cloudstack-agent status cloudstack-agent (pid 109382) 正在运行... [root@node5 bin]# netstat -antp |grep 8250 tcp 0 0 192.168.14.20:22220 192.168.14.10:8250 ESTABLISHED 109382/jsvc.exec
处理后状态恢复正常，但是libvirtd仍然无法杀掉, 很快netstat -antp |grep 8250 状态再次消失，cloudstack master平台监控主机记录由Up状态转为disconnect状态。不过毕竟不是down状态，较之前已经有了进步。
启动一个libvirtd -d看下，
[root@node5 bin]# libvirtd -d [root@node5 bin]# ps ax |grep libvirtd 6485 ? R 863:37 libvirtd --daemon -l 130057 ? Sl 0:38 libvirtd -d 28904 pts/0 S+ 0:00 grep libvirtd
然后在cloudstack master平台上手工点击强制重新连接该主机，成功了。主机监控状态由disconnect转为Up，这时再次尝试杀掉6485仍然是不成功的，于是又在cloudstack master管理平台上尝试着点击操作了一下暂停vm命令，vm成功暂停。再返回服务器上观察原来hung死的libvirtd进程已经消失。
[root@node5 bin]# libvirtd -d [root@node5 bin]# ps ax |grep libvirtd 130057 ? Sl 0:38 libvirtd -d 28904 pts/0 S+ 0:00 grep libvirtd
至此既恢复了平台对该主机的管控，也终止了libvirtd异常进程。问题初步归于cloudstack-agent在处理发送个libvirtd的信号上存在些小问题。以后再单独分析下jsvc进程，再现问题和根本解决。
问题反思
在处理服务异常的问题上，命令行参数不要用restart，用stop和kill来调试。说起来都是泪！
