Если вы запускаете Manticore Search на Linux, в качестве основного инструмента управления стоит выбрать systemd.

На текущий момент это общепринятая практика, хотя ранее существовали определённые ограничения. Да, Manticore Search мог работать под systemd, но интеграция обладала рядом функциональных ограничений. Архитектура демона основана на традиционных подходах Unix; systemd появился позже и хотел от службы совсем другого. Так что настройка работала, но не соответствовала современным требованиям к управлению службами.

Теперь Manticore Search поддерживает нативные уведомления systemd — это и есть главное изменение.

Почему это важно? Потому что устраняется ряд операционных проблем:

• systemctl status показывает достоверные данные о статусе службы

• становится легче отслеживать состояние службы при запуске и перезагрузке конфигурации

• вывод логов перенаправляется в журнал systemd

• завершение работы безопаснее, когда realtime-таблицы сбрасывают данные

• необходимость в PID-файлах значительно уменьшается

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

Начнём с завершения работы — именно здесь чаще всего и возникают реальные проблемы

Главное преимущество этого изменения неочевидно на первый взгляд. Это поведение при завершении работы.

Если Manticore Search сбрасывает данные из realtime-таблиц, завершение работы может занять время. В прежних конфигурациях зачастую приходилось использовать searchd --stopwait и полагаться на удачу. В некоторых случаях этого было достаточно. Иногда — нет.

Сценарий сбоя неудобный и проблематичный: systemd определяет, что служба не отвечает, ждет достаточно долго, а затем отправляет SIGKILL. Если Manticore Search в этот момент как раз выполняет сброс данных, это, пожалуй, худший момент, чтобы принудительно остановить процесс.

Новое поведение обеспечивает координированное взаимодействие со systemd. Пока Manticore Search продолжает сбрасывать данные, он отправляет systemd сигнал о необходимости продления тайм-аута. Конкретно, он отправляет уведомления о продлении тайм-аута каждые 15 секунд, каждый раз запрашивая еще 30 секунд.

Это, пожалуй, важнее почти всех остальных улучшений в статье. Более информативный статус — это хорошо. Аккуратная перезагрузка — тоже хорошо. Но не сломать процесс завершения работы во время сброса данных RT-таблиц — ещё важнее.

Замедленное завершение работы более не воспринимается ошибочно как проблема. Иногда это просто значит, что сервер заканчивает именно ту часть работы, которая действительно важна.

Как выглядела старая схема

Исторически Manticore Search использовал стандартный для Unix шаблон работы демона: отсоединиться от терминала и выполнить двойной fork для перехода в фоновый режим, записать PID-файл и продолжить работу. В этом не было ничего необычного. Если для вас важна переносимость, вы довольно быстро придёте именно к такой схеме.

Появлялись проблемы совместимости, когда эту модель смешивали с systemd.

Поддержка имелась, но была ограничена. Юнит-файл полагался на то, что демон корректно выполнил fork, что PID-файл существует и по-прежнему указывает на правильный процесс. При корректной работе все функционировало штатно. Когда возникали ошибки, мониторинг становился неточным.

Типичные слабые места были предсказуемыми:

• отслеживание процесса зависело от внешнего файла

• отчет о состоянии был косвенным

• ход запуска был по большей части не виден самому systemd

• перезагрузку конфигурации и завершение работы было сложнее нормально отслеживать

Теоретически эти проблемы могут показаться незначительными. Однако на практике администраторы часто сталкиваются с неопределённостью: действительно ли служба работает корректно — или просто пока ещё запущена.

Один конкретный пример следует иметь в виду. Если встроенный watchdog Manticore Search выполнял перезапуск searchd после сбоя, systemd мог продолжать следить за исходным процессом, а не за вновь поднявшимся демоном. Отсюда и предупреждения вроде Supervising process ... which is not our child.

Менее заметный, но распространенный сценарий сбоя — расхождение в настройках конфигурации: измените путь pid_file в Manticore Search, забудьте обновить юнит-файл, и systemd начнет следить не за тем местом. Демон может уже работать, а systemctl status будет рассказывать куда менее полезную историю.

Этот скриншот чётко иллюстрирует старую схему. systemd видел дерево процессов, но не всегда видел жизненный цикл службы так, как вам было нужно.

Юнит-файл на основе notify

Новая схема использует Type=notify, что позволяет Manticore Search напрямую сообщать о своем состоянии, вместо того чтобы заставлять systemd слишком многое выводить из PID-файла и догадок.

Теперь юнит-файл systemd выглядит так:

[Unit]
Description=Manticore Search Engine
...

[Service]
Type=notify
...

ExecStart=/usr/bin/searchd --config /etc/manticoresearch/manticore.conf --nodetach $_ADDITIONAL_SEARCHD_PARAMS
...

Restart=on-failure
...

Здесь важны несколько деталей.

Type=notify означает, что systemd ожидает обновления состояния прямо от Manticore Search.

--nodetach удерживает searchd на переднем плане. Под systemd это правильное поведение по умолчанию. Все остальное — ненужные дополнительные шаги. Сам флаг не новый; изменилось то, что теперь он входит в поставляемую конфигурацию systemd, а не воспринимается как опция только для отладки.

PIDFile больше не является основным механизмом мониторинга, но его все еще можно при необходимости добавить вручную, если у вас есть старые инструменты, которые его ждут.

С такой схемой Manticore Search может сообщать о состояниях вроде:

• запуска

• загрузки таблиц

• перезагрузки

• готовности

Звучит не особо впечатляюще. Но по сравнению со старой моделью «процесс есть, значит, наверное, все нормально» это реальное улучшение.

Ещё одна приятная деталь: перезагрузка стала менее хлопотной

Перезагрузка Manticore Search традиционно означала отправку SIGHUP процессу searchd. Под systemd происходит то же самое. Поставляемый юнит-файл использует:

ExecReload=/bin/kill -HUP $MAINPID

Так что systemctl reload manticore не перезапускает демон. Он отправляет SIGHUP работающему searchd, который инициирует ротацию таблиц: Manticore Search повторно открывает plain tables и переключается на заново собранные файлы таблиц без полного перезапуска демона.

Это важное различие. Команда reload — менее рискованный способ запустить ротацию таблиц: службу не нужно предварительно останавливать. В зависимости от настройки seamless_rotate новые запросы могут ненадолго подвиснуть, а клиенты могут увидеть временные ошибки во время окна ротации. restart — это уже совсем другая операция: он останавливает службу, а затем запускает ее заново.

Теперь этот процесс виден в статусе службы. Когда ротация начинается, Manticore Search сообщает RELOADING=1 в systemd; когда она заканчивается, снова сообщает READY=1. Поэтому systemctl status manticore может показать, что демон действительно выполняет ротацию, а не просто находится в общем состоянии запущенной службы.

--nodetach еще и исправляет схему логирования

Этот флаг не новый. Изменилось его окружение.

Когда Manticore Search остаётся прикреплённым к systemd, а не уходит в фоновый режим, логи попадают в журнал, а главным процессом становится тот, о котором systemd действительно знает. Меньше посредников. Обычно это окупается со временем, а не сразу. До --nodetach стартовые сообщения могли начинаться в journalctl, а потом остальная история переезжала в собственные файлы логов Manticore Search после ухода в фон.

Так что для многих установок обычных инструментов вполне достаточно:

journalctl -u manticore
journalctl -u manticore -f
journalctl -u manticore --since "1 hour ago"

Простые схемы логирования — это удобно. Ценность единого места, куда нужно смотреть в первую очередь, часто недооценивают.

Если вас устраивает журнал systemd как основное место хранения логов, старая схема логирования в manticore.conf может быть уже не нужна. Часто это элемент, не нуждающийся в дополнительной настройке.

О внутреннем watchdog

Если Manticore Search работает под systemd, проще всего поступить так: пусть службой управляет systemd, а внутренний watchdog Manticore Search не включайте, если он вам действительно не нужен.

Можно ли использовать оба механизма? Да. Стоит ли так делать в обычной установке? Нет.

Если вы явно включите внутренний watchdog, модель мониторинга станет менее прямой, и могут появляться предупреждения вида:

Supervising process ... which is not our child

Эта конфигурация поддерживается. Но для большинства людей это избыточные компоненты.

Несколько замечаний в дополнение

При мониторинге на основе уведомлений PID-файлы самому systemd нужны гораздо меньше. Возможно, вы сможете убрать pid_file из конфигурации, но только если больше никто в вашей среде на него не рассчитывает. Старые скрипты обычно живут дольше, чем кто-либо ожидает.

Если вы используете исполняемые конфигурационные файлы, включая конфиги на основе shebang, например #!/usr/bin/env python, такая схема работает надёжнее, чем некоторые старые подходы к управлению службами.

Команды, которые вы действительно будете использовать

sudo systemctl start manticore
sudo systemctl stop manticore
sudo systemctl restart manticore
sudo systemctl reload manticore
sudo systemctl status manticore
sudo systemctl enable manticore

И для логов:

sudo journalctl -u manticore
sudo journalctl -u manticore -f
sudo journalctl -u manticore --since "1 hour ago"

По сути, это все.

Итоговый результат может показаться не слишком заметным: Manticore Search теперь ведёт себя как обычная современная системная служба, а не как традиционный Unix-демон, под который раньше всем приходилось подстраиваться. Но именно такие изменения инфраструктуры часто и бывают лучшими. Они устраняют скрытые неудобства, которые со временем стали привычными.