Пишем Upstart скрипт

Пишем Upstart скрипт

Upstart — это система инициализации ОС, которая управляет запуском демонов в течение загрузки системы, их остановку, а также управляет ими во время работы системы. Основанная на событиях замена системы инициализации init в UNIX и Linux системах. Изначально разрабатывалась для дистрибутива Ubuntu, но предназначен для развертывания во всех дистрибутивах Linux в качестве альтернативной замены.

Основные характеристики

  • Задачи и службы запускаются и/или останавливаются через события;
  • События генерируются при запуске и остановке задач и сервисов;
  • События могут быть получены от любого другого процесса в системе;
  • Слыжбы могут быть возрождены, если они неожиданно кильнулись;
  • Наблюдение и возрождение демонов, которые отделены от их родительского процесса;
  • Связь с init демоном через D-Bus;
  • Пользовательские сервисы, которые пользователи могут запускать и останавливать сами.

И так, хотелось бы рассказать как можно запускать томкат. Но для начала, нужно узнать какой механизм инициализации используется:

Т.к речь идет о Upstart, то и продолжим тему.

PS: Вот еще полезное чтиво:

Система инициализации в Unix/Linux

Система инициализации Systemd

Система инициализации SysVinit

Пишем systemd Unit файл

Инициализация — важнейшая процедура, лежащая в основе любой операционной системы на основе Unix/Linux для управления работой каждого скрипта и службы.

По сути, инициализация следует за этим процессом:

  • Загрузка сервера.
  • Запуск init процесса (обычно как PID 1).
  • Запуск предопределенного набора задач для запуска активируется последовательно.

Инициализация отвечает за то, чтобы сервер мог загрузиться и отключиться. В некоторых Unix/Linux дистрибутивах  используется стандартный процесс инициализации init/systemD/Upstart. В этой статье я расскажу о том, как использовать Upstart или Init.

Традиционная инициализация следует за линейным процессом: загрузка отдельных задач в предопределенную последовательность при загрузке системы. Это не так полезно, особенно в быстро меняющихся ситуациях. Чтобы понять, почему, представьте, например, вы изменили среду сервера, добавив дополнительное устройство хранения.

Процесс инициализации не может принимать во внимание внезапные изменения в среде, а это означает, что ваш облачный сервер должен быть повторно инициализирован, прежде чем он сможет распознать дополнительное хранилище. Обнаружение «на лету» — это то, что необходимо, хотя это не возможность классической процедуры инициализации.

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

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

Синхронные последовательности загрузки больше не желательны. На смену init-у, пришел Upstart — решение этих проблем с расширенными возможностями.

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

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

Jobs

В мире Upstart, jobs — это рабочие процессы, разделенные на задания (целью) и рабочие задания (которые могут выполняться в фоновом режиме). Существуют также абстрактные задания — процессы, которые выполняются всегда, до тех пор, пока пользователь не будет заблокирован административными привилегиями.

Events

Однако событиями являются сигналы или «вызовы», используемые для запуска определенного действия с заданием или другим событием. Общие формы событий относятся к мониторингу процесса: запуск (пред-запуск) и остановка (пред-остановка).

Emitting Events

Процесс трансляции события называется «испусканием» (emitting). Обычно это вызвано состоянием процесса или задания, хотя администратор также может выпустить событие вручную, выпустив «initctl emit <event>» команду.

Состояния Job и Events

Джобы (задания или job-ы) в системе находятся в каталоге /etc/init/, а задания пользователя находятся в собственном каталоге ~/.init/.

Пользовательские задания запускаются в собственной сессии пользователя, поэтому они также известны как сеансовые задания. Они не работают в общесистемном режиме и не входят в обозначение PID1.

Независимо от его типа, задание всегда определяется в файле конфигурации (.conf), где его имя файла должно представлять связанную службу или задачу.

У каждой из этих заданий есть цель — запустить или остановить. Между этими двумя целями находятся множество состояний задач, которые определяют текущие действия работы в отношении цели. Важными являются следующие состояния:

  • waiting: Начальное состояние процесса.
  • starting: Запуск джобы.
  • pre-start: Загрузка или пред-старт некоторых действий.
  • spawned: Начало скрипта.
  • post-start: После-запуск или действия после запуска задания.
  • running: Запущенная джоба.
  • pre-stop: Пред-остановка или действия который выполняються перед остановкой задания.
  • stopping: Остановка джобы.
  • killed: Прибиваение процесса. Остановка задания.
  • post-stop: После-остановка или действия после остановки джобы.

После post-start состояния, задание определяется как running (запущено). Он остается включенным до тех пор, пока не будет выполнена предварительная остановка, когда задание будет готово к остановке, тогда работа будет убита, а процедуры очистки после остановки выполнят свои действия( если они будут определены).

Вы можете просмотреть, как задание переходит между состояниями, установив приоритет системного журнала Upstart (расположенный в каталоге /var/ log/upstart/) для отладки с помощью этой команды:

Помните, что состояния не являются событиями, а события не являются состояниями. Четыре события (starting, started, stopping и stopped) испускаются Upstart, но состояния задачи определяют переход между этапами жизненного цикла работы.

Примеры Upstart скриптов

Открываем (создаем) файл:

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

Тем самым, я описал что это за скрипт (поле description) и прописал автора (поле — author). После чего, сейчас я пропишу следующую строку для того чтобы это задание выполнялось после того, как системные службы и процессы уже загружены (чтобы предотвратить конфликт):

Возможно, вам интересно, что такое уровень запуска. По сути, это единственное значение, которое представляет текущую конфигурацию системы. [2345] относится ко всем состояниям конфигурации с общим доступом к Linux и сетям, что идеально подходит для базового тестового примера.

Идем дальше и прописываем следующей строчкой:

Это остановит созданную задачу при отключения питания (завершения работы) сервера.

Затем мы добавим код выполнения:

Определим действия перед запуском:

Так же, определим пред-остановку:

Сохраните и закройте этот файл.

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

Если обнаружены какие-либо проблемы, эта команда укажет номер конкретную линию(ии) и проблему. Однако с тестовым заданием вы должны увидеть вывод следующим образом:

Эта команда может использоваться для управления заданиями Upstart и другими фоновыми службами, такими как веб-сервер.

Основной синтаксис команды:

Где, <control> может быть:

  • restart — Перезапустит службу.
  • start — Запустит службу.
  • stop — Остановит службу.
  • status — Проверит состояние службы.

Давайте запустим написанный скрипт:

Теперь проверьте файл testjob.log, выполнив следующую команду:

Я не буду больше заострять внимания т.к это уже не актуально и в большенстве случаев, уже используется systemD/init скрипты.

Вот и все, статья «Пишем Upstart скрипт» завершена.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *