自定義的Linux守護進程將不會停止使用「服務停止」

我已經編寫了一個自定義的python守護進程，它通過ubuntu 14.04上的init.d腳本作爲服務運行。啓動服務工作正常，但是當我嘗試執行「服務監視器停止」時，守護程序不會終止。我正在使用pyinotify爲文件觀察器進行daemonize更改。自定義的Linux守護進程將不會停止使用「服務停止」

內的init.d腳本：

PATH=/sbin:/usr/sbin:/bin:/usr/bin 
DESC="Monitor files" 
NAME=monitor 
DAEMON=/usr/bin/python 
DAEMON_ARGS="/home/user/python/monitor.py" 
PIDFILE=/home/user/logs/monitor.pid 
LOGFILE=/home/user/logs/monitor.log 
SCRIPTNAME=/etc/init.d/$NAME

...

do_stop() 
{ 
    # Return 
    # 0 if daemon has been stopped 
    # 1 if daemon was already stopped 
    # 2 if daemon could not be stopped 
    # other if a failure occurred 
    start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME 
    RETVAL="$?" 
    # Many daemons don't delete their pidfiles when they exit. 
    rm -f $PIDFILE 
    return "$RETVAL" 
    echo "done" 
}

...

case "$1" in 
    start) 
    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME" 
    do_start 
    case "$?" in 
      0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 
      2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; 
    esac 
    ;; 
    stop) 
    [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME" 
    do_stop 
    case "$?" in 
      0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 
      2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; 
    esac 
    ;;

...

爲了確保守護程序處理SIGERM正確，我可以手動運行它：

bash$ /usr/bin/python /home/user/python/monitor.py 
bash$ kill -Term PID

守護程序成功處理SIGTERM並正確退出。

雖然我做了「服務監視器停止」，但我似乎無法弄清楚它爲什麼不處理它。

來源

2016-03-15 R. W.

運行時，PIDFILE是否包含正確的進程ID？從您的命令行示例中，它看起來像'monitor.py'自己變成了一個後臺進程，所以'start-stop-daemon'可能會記錄錯誤的PID –

我以前的評論假設'start-stop-daemon'已經告訴'--make-pidfile'，否則就要用'monitor.py'寫出來。（'do_start'不在問題中） –

是的，這是正確的，python程序確實將其自身轉換爲後臺進程，並且PIDFILE中的PID與進程的PID相匹配。是的，它在python程序中創建了自己的PIDFILE。 –

檢查傳送到start-stop-daemon --stop命令的過程$NAME是否正確。我剛剛遇到了這個問題，因爲我正在運行的一個進程最終得到一個不同的名稱，只要它分支它的守護進程。嘗試運行此看到進程的命令名稱：

ps -o comm= $(cat /home/user/logs/monitor.pid)

我敢打賭，你輸出這個（而不是monitor）：

python

然後改變你的止損指令看起來像這樣，在那裏你替補python$NAME：

start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name python

來源

2016-03-24 02:33:35

是的，你100％正確。該進程已被重命名爲python。你的建議修復了它。作爲一個後續，可能會增加「python」與其他系統進程的名稱衝突後？有沒有更好的做法讓我的守護進程正確命名？ –

您可能正在尋找類似[this]（http://stackoverflow.com/questions/564695/is-there-a-way-to-change-effective-process-name-in-python）。這可能不值得所有的努力;如果您的'$ PIDFILE'得到了適當的保護（不可信的用戶不可寫入），那麼風險應該很低，以至於最終會導致錯誤的基於Python的進程被終止。只要'$ PIDFILE'存在於'/ var/run'（通常是tmpfs）中，它就會在重新啓動時被刪除，這將進一步降低可能性。 –

很高興知道，謝謝！ –

自定義的Linux守護進程將不會停止使用「服務停止」

回答

相關問題