Версия:

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

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

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

Во время событийного цикла в потоке обработки транзакций 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
        -- Logs begin at Fri 2016-01-08 12:21:53 MSK, end at Thu 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.