Назад | Перейти на главную страницу

сценарий инициализации завершается сеансом ssh

Нам нужно бежать pt-стебель на нескольких серверах, чтобы следить за mySQL, и мне надоело вручную запускать его каждый раз при перезагрузке сервера. Небольшой поиск в Google обнаружил сценарий инициализации для pt-stalk, и, похоже, он работал нормально. [моя слегка измененная версия включена внизу этого сообщения]

Слишком долго приходилось выяснять, как запустить сценарий и настроить его через ssh [длинная история, пожалуйста, не спрашивайте], поэтому я решил просто войти на 20 с лишним серверов и настроить все вручную, и все заработало.

Через пару дней мой коллега прокомментировал, что он получает электронные письма, но я явно не получал, и похоже, что я указал неправильный адрес электронной почты в конфигурации. На этот раз я понял, как отправить изменение через ssh, и закончил все с помощью:

for server in `cat serverlist.txt`; do
  ssh -t $server sudo -i service pt-stalk restart
done

И это момент, когда pt-stalk перестал работать на каждом сервере с:

2013_08_23_11_43_20 Caught signal, exiting
2013_08_23_11_43_20 Exiting because OKTORUN is false
2013_08_23_11_43_20 /usr/bin/pt-stalk exit status 1
2013_08_23_11_43_22 Starting /usr/bin/pt-stalk --function=status --variable=Threads_connected --threshold=100 --match= --cycles=5 --interval=1 --iterations= --run-time=30 --sleep=300 --dest=/var/lib/pt-stalk --prefix= --notify-by-email=servers@domain.com --log=/var/log/pt-stalk.log --pid=/var/run/pt-stalk.pid
2013_08_23_11_43_22 Caught signal, exiting

В ходе вчерашнего тестирования я расшифровал, что «сигнал пойман, выход» означает, что он поймал HUP/TERM/KILL. Первый из service pt-stalk restart, а второй один сразу после успешный начало - это когда закрывается сеанс ssh. wat.jpg

Если я просто подключусь к серверу по ssh, введите sudo -i service pt-stalk start или restart Я могу выйти, и это благополучно продолжается. Однако, если я просто передаю команду ssh, как в приведенном выше цикле pt-stalk, он улавливает сигнал и выходит. Иногда ловит два сигналы перед выходом.

Что, черт возьми, происходит?


Мой /etc/init.d/pt-stalk для справки:

#!/usr/bin/env bash
# chkconfig: 2345 20 80
# description: pt-stalk
### BEGIN INIT INFO
# Provides: pt-stalk
# Required-Start: $network $named $remote_fs $syslog
# Required-Stop: $network $named $remote_fs $syslog
# Should-Start: pt-stalk
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON="/usr/bin/pt-stalk"
DAEMON_OPTS="--config /etc/pt-stalk.conf"
NAME="pt-stalk"
DESC="pt-stalk"
PIDFILE="/var/run/${NAME}.pid"
STALKHOME="/var/lib/pt-stalk"

test -x $DAEMON || exit 1

[ -r /etc/default/pt-stalk ] && . /etc/default/pt-stalk

#. /lib/lsb/init-functions

sig () {
    test -s "$PIDFILE" && kill -$1 `cat $PIDFILE`
}

start() {
  if [[ -z $MYSQL_OPTS ]]; then
HOME=$STALKHOME $DAEMON $DAEMON_OPTS
  else
HOME=$STALKHOME $DAEMON $DAEMON_OPTS -- $MYSQL_OPTS
  fi
return $?
}

stop() {
  if sig TERM; then
    while sig 0 ; do
      echo -n "."
      sleep 1
    done
    return 0
  else
    echo "$DESC is not running."
    return 1
  fi
}

status() {
  if sig 0 ; then
    echo "$DESC (`cat $PIDFILE`) is running."
    return 0
  else
    echo "$DESC is stopped."
    return 1
  fi
}

log_begin_msg() {
        echo $1
}

log_end_msg() {
        if [ $1 -eq 0 ]; then
                echo "Success"
        else
                echo "Failure"
        fi
}

case "$1" in
  start)
   log_begin_msg "Starting $DESC"
   start
   log_end_msg $?
   ;;

  stop)
   log_begin_msg "Stopping $DESC"
   stop
   log_end_msg $?
   ;;
  status)
    status ;;

  restart)
    log_begin_msg "Restarting $DESC"
    stop
    sleep 1
    start
    log_end_msg $?
    ;;

  *)
    echo "Usage: $0 {start|stop|status|}" >&2
    exit 1
    ;;
esac

Поскольку ваш демон немедленно завершается, я почти уверен, что если --daemonize вариант предоставляется /usr/bin/pt-stalk он может не закрыть один из файловых дескрипторов stdin, stdout или stderr должным образом и достаточно рано или / и не справляется с SIGHUP сигнал правильно.

Чтобы проверить, какое из моих предположений верно, измените свой init скрипт, чтобы ввод и вывод start перенаправлены с и на /dev/null. Пример:

start </dev/null >/dev/null 2>/dev/null

Если это устранит проблему раннего завершения, сузьте ее, удалив эти перенаправления одно за другим снова. Может быть что pt-stalk просто вилки рано. В этом случае вставка другого sleep 1 после звонка start также может обойти это. Если дело доходит до обработки SIGHUP signal, то это также может быть обходным путем для изменения вашего init скрипт, добавив это:

trap "echo SIGHUP ignored" 1

перед звонком в start и это:

trap - 1

сразу после звонка start.

Я не скачивал pt-stalk и не изучал это и не проверял мою теорию, описанную выше. Это все из моего опыта с другими демонами.