Версия:

Контроль за фоновыми программами

Контроль за фоновыми программами

Сигналы от сервера

Во время событийного цикла в потоке обработки транзакций Tarantool обрабатывает следующие сигналы:

Сигнал Эффект
SIGHUP Может привести к ротации журналов, см. пример в справочнике по параметрам журналирования Tarantool’а.
SIGUSR1 Может привести к созданию снимка состояния базы данных, см. описание функции box.snapshot.
SIGTERM Может привести к корректному завершению работы (с предварительным сохранением всех данных).
SIGINT (или «прерывание от клавиатуры») Может привести к корректному завершению работы.
SIGKILL Приводит к аварийному завершению работы.

Остальные сигналы приводят к заданному операционной системой поведению. Все сигналы, за исключением SIGKILL, можно игнорировать, особенно если Tarantool выполняет длительную процедуру и не может вернуться в событийный цикл в потоке обработки транзакций.

Автоматическая перезагрузка экземпляра

На платформах, где доступна утилита systemd, systemd автоматически перезагружает все экземпляры Tarantool’а при сбое. Чтобы продемонстрировать это, отключим один из экземпляров:

$ systemctl status tarantool@my_app|grep PID
  Main PID: 5885 (tarantool)
  $ tarantoolctl enter my_app
  /bin/tarantoolctl: Found my_app.lua in /etc/tarantool/instances.available
  /bin/tarantoolctl: Connecting to /var/run/tarantool/my_app.control
  /bin/tarantoolctl: connected to unix/:/var/run/tarantool/my_app.control
  unix/:/var/run/tarantool/my_app.control> os.exit(-1)
  /bin/tarantoolctl: unix/:/var/run/tarantool/my_app.control: Remote host closed connection

А теперь убедимся, что systemd перезапустила его:

$ systemctl status tarantool@my_app|grep PID
  Main PID: 5914 (tarantool)

И под конец проверим содержимое журнала загрузки:

$ journalctl -u tarantool@my_app -n 8
  -- Записи начинаются в пятницу 08.01.2016 12:21:53 MSK, заканчиваются в четверг 21.01.2016 2016-01-21 21:09:45 MSK. --
  Jan 21 21:09:45 localhost.localdomain systemd[1]: tarantool@my_app.service: Unit entered failed state.
  Jan 21 21:09:45 localhost.localdomain systemd[1]: tarantool@my_app.service: Failed with result 'exit-code'.
  Jan 21 21:09:45 localhost.localdomain systemd[1]: tarantool@my_app.service: Service hold-off time over, scheduling restart.
  Jan 21 21:09:45 localhost.localdomain systemd[1]: Stopped Tarantool Database Server.
  Jan 21 21:09:45 localhost.localdomain systemd[1]: Starting Tarantool Database Server...
  Jan 21 21:09:45 localhost.localdomain tarantoolctl[5910]: /usr/bin/tarantoolctl: Found my_app.lua in /etc/tarantool/instances.available
  Jan 21 21:09:45 localhost.localdomain tarantoolctl[5910]: /usr/bin/tarantoolctl: Starting instance...
  Jan 21 21:09:45 localhost.localdomain systemd[1]: Started Tarantool Database Server.

Создание дампов памяти

Tarantool создает дамп памяти при получении одного из следующих сигналов: SIGSEGV, SIGFPE, SIGABRT или SIGQUIT. При сбое Tarantool’а дамп создается автоматически.

На платформах, где доступна утилита systemd, coredumpctl автоматически сохраняет дампы памяти и трассировку стека при аварийном завершении Tarantool-сервера. Вот как включить создание дампов памяти в Unix-системе:

  1. Убедитесь, что лимиты для сессии установлены таким образом, чтобы можно было создавать дампы памяти, – выполните команду ulimit -c unlimited. Также проверьте «man 5 core» на другие причины, по которым дамп памяти может не создаваться.
  2. Создайте директорию для записи дампов памяти и убедитесь, что в эту директорию действительно можно производить запись. На Linux путь до директории задается в параметре ядра, который настраивается через /proc/sys/kernel/core_pattern.
  3. Убедитесь, что дампы памяти включают трассировку стека. При использовании бинарного дистрибутива Tarantool’а эта информация включается автоматически. При сборке Tarantool’а из исходников, если передать CMake флаг -DCMAKE_BUILD_TYPE=Release, вы не получите подробной информации.

Для симуляции сбоя можно попытаться выполнить нелегальную команду на работающем экземпляре Tarantool’а:

$ # !!! пожалуйста, никогда не делайте этого на боевом сервере !!!
  $ tarantoolctl enter my_app
  unix/:/var/run/tarantool/my_app.control> require('ffi').cast('char *', 0)[0] = 48
  /bin/tarantoolctl: unix/:/var/run/tarantool/my_app.control: Remote host closed connection

Есть другой способ: если вы знаете PID экземпляра ($PID в нашем примере), можно остановить этот экземпляр, запустив отладчик gdb:

$ gdb -batch -ex "generate-core-file" -p $PID

или послав вручную сигнал SIGABRT:

$ kill -SIGABRT $PID

Примечание

Чтобы узнать PID экземпляра, можно:

  • посмотреть его с помощью box.info.pid,
  • использовать команду ps -A | grep tarantool, или
  • выполнить systemctl status tarantool@my_app|grep PID.

Чтобы посмотреть на последние сбои Tarantool-демона на платформах, где доступна утилита systemd, выполните команду:

$ coredumpctl list /usr/bin/tarantool
  MTIME                            PID   UID   GID SIG PRESENT EXE
  Sat 2016-01-23 15:21:24 MSK   20681  1000  1000   6   /usr/bin/tarantool
  Sat 2016-01-23 15:51:56 MSK   21035   995   992   6   /usr/bin/tarantool

Чтобы сохранить дамп памяти в файл, выполните команду:

$ coredumpctl -o filename.core info <pid>

Трассировка стека

Так как Tarantool хранит кортежи в памяти, файлы с дампами памяти могут быть довольно большими. Чтобы найти проблему, обычно целый файл не нужен – достаточно только «трассировки стека» или «обратной трассировки».

Чтобы сохранить трассировку стека в файл, выполните команду:

$ gdb -se "tarantool" -ex "bt full" -ex "thread apply all bt" --batch -c core> /tmp/tarantool_trace.txt

где:

  • «tarantool» – это путь до исполняемого файла Tarantool’а,
  • «core» – это путь до файла с дампом памяти, и
  • «/tmp/tarantool_trace.txt» – это пример пути до файла, в который сохраняется трассировка стека.

Примечание

Иногда может оказаться, что файл с трассировкой стека не содержит отладочных символов – в таких строках вместо имени будет стоять ”??”. Если это произошло, ознакомьтесь с инструкциями на этих двух wiki-страницах Tarantool’а: How to debug core dump of stripped tarantool и How to debug core from different OS.

Чтобы получить трассировку стека и прочую полезную информацию в консоли, выполните команду:

$ coredumpctl info 21035
            PID: 21035 (tarantool)
            UID: 995 (tarantool)
            GID: 992 (tarantool)
         Signal: 6 (ABRT)
      Timestamp: Sat 2016-01-23 15:51:42 MSK (4h 36min ago)
   Command Line: tarantool my_app.lua <running>
     Executable: /usr/bin/tarantool
  Control Group: /system.slice/system-tarantool.slice/tarantool@my_app.service
           Unit: tarantool@my_app.service
          Slice: system-tarantool.slice
        Boot ID: 7c686e2ef4dc4e3ea59122757e3067e2
     Machine ID: a4a878729c654c7093dc6693f6a8e5ee
       Hostname: localhost.localdomain
        Message: Process 21035 (tarantool) of user 995 dumped core.

                 Stack trace of thread 21035:
                 #0  0x00007f84993aa618 raise (libc.so.6)
                 #1  0x00007f84993ac21a abort (libc.so.6)
                 #2  0x0000560d0a9e9233 _ZL12sig_fatal_cbi (tarantool)
                 #3  0x00007f849a211220 __restore_rt (libpthread.so.0)
                 #4  0x0000560d0aaa5d9d lj_cconv_ct_ct (tarantool)
                 #5  0x0000560d0aaa687f lj_cconv_ct_tv (tarantool)
                 #6  0x0000560d0aaabe33 lj_cf_ffi_meta___newindex (tarantool)
                 #7  0x0000560d0aaae2f7 lj_BC_FUNCC (tarantool)
                 #8  0x0000560d0aa9aabd lua_pcall (tarantool)
                 #9  0x0000560d0aa71400 lbox_call (tarantool)
                 #10 0x0000560d0aa6ce36 lua_fiber_run_f (tarantool)
                 #11 0x0000560d0a9e8d0c _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_ (tarantool)
                 #12 0x0000560d0aa7b255 fiber_loop (tarantool)
                 #13 0x0000560d0ab38ed1 coro_init (tarantool)
                 ...

Отладчик

Для запуска отладчика gdb, выполните команду:

$ coredumpctl gdb <pid>

Мы очень рекомендуем установить пакет tarantool-debuginfo, чтобы сделать отладку средствами gdb более эффективной. Например:

$ dnf debuginfo-install tarantool

С помощью gdb можно узнать, какие еще debuginfo-пакеты нужно установить:

$ gdb -p <pid>
  ...
  Missing separate debuginfos, use: dnf debuginfo-install
  glibc-2.22.90-26.fc24.x86_64 krb5-libs-1.14-12.fc24.x86_64
  libgcc-5.3.1-3.fc24.x86_64 libgomp-5.3.1-3.fc24.x86_64
  libselinux-2.4-6.fc24.x86_64 libstdc++-5.3.1-3.fc24.x86_64
  libyaml-0.1.6-7.fc23.x86_64 ncurses-libs-6.0-1.20150810.fc24.x86_64
  openssl-libs-1.0.2e-3.fc24.x86_64

В трассировке стека присутствуют символические имена, даже если у вас не установлен пакет tarantool-debuginfo.