Python 当使用netstat-lntp检测侦听端口的进程是否关闭时,netstat出现异常?

Python 当使用netstat-lntp检测侦听端口的进程是否关闭时,netstat出现异常?,python,linux,netstat,Python,Linux,Netstat,我编写了一个脚本,其性能类似于supervisord,可以检测进程是否停止。当服务器停机时,启动它有时我发现进程正在运行,但脚本认为进程已停止。 def check_status(service, port): """ check_the service status. args: service: the name of the service. port: """ cmd = "netstat -lntp | g

我编写了一个脚本,其性能类似于supervisord,可以检测进程是否停止。当服务器停机时,启动它有时我发现进程正在运行,但脚本认为进程已停止。

def check_status(service, port):
    """
        check_the service status.
    args:
        service: the name of the service.
        port:
    """
    cmd = "netstat -lntp | grep %s | grep %s | awk -F '[:]' '{print $2}'" % (service, port)
    logger.info(cmd+"\n")
    results = os.popen(cmd).readlines()
    logger.info(results)
    return bool(results)
以下是日志:

2017-04-02 07:53:02,006,1491090782.006675,INFO-netstat -lntp | grep uwsgi | grep 8083 | awk -F '[:]' '{print $2}'

2017-04-02 07:53:02,043,1491090782.043374,INFO-[]
2017-04-02 07:53:02,043,1491090782.043619,INFO-2017-04-02 07:53:02 [ERROR] uwsgi:8083 is down.

2017-04-02 07:53:02,043,1491090782.043733,INFO-2017-04-02 07:53:02 [INFO] try to start uwsgi:8083

2017-04-02 07:53:02,043,1491090782.043814,INFO-cmd:sh /usr/local/sandai/webrtc-env/apprtc/sbin/apprtc.sh start  8083
2017-04-02 07:53:03,100,1491090783.100647,INFO-netstat -lntp | grep uwsgi | grep 8083 | awk -F '[:]' '{print $2}'

2017-04-02 07:53:03,138,1491090783.138201,INFO-['8083                0.0.0.0\n']
2017-04-02 07:53:03,138,1491090783.138506,INFO-2017-04-02 07:53:03 [INFO] uwsgi have been started.
但是当我使用ps-ef | grep uwsgi | grep 8083时,我发现服务器没有关闭:

[ops01@test 2017.04.02]# ps -ef | grep uwsgi | grep 8083
ops01    22684     1  0  2016 ?        00:03:14 uwsgi --plugin    http,python,gevent --http :8083
使用netstat来检测进程是否停止是不合适的吗?为什么?谢谢

“服务器正在运行”和“服务器在端口上侦听”本质上是两件不同的事情。根据服务器的实现方式,可能会发生这样的情况:进程本身正在运行,但无法开始侦听端口。此外,在启动服务器和服务器实际开始侦听端口之间,始终存在一些窗口

为此,我通常使用两个单独的过程:

  • supervisor进程正在确保服务器进程本身正在运行—可以使用fork()/wait()函数(或其python对应函数)可靠地检测到这一点。如果服务器死机,则可以重新启动
  • 监控过程确保服务器正常工作。在这里,你必须考虑到你可能有假阳性,并增加一些重试/双重检查。如果发现该服务器不起作用,它可以通知主管重新启动服务器,或者杀死服务器本身,让主管重新启动它