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

Принятие

Дистрибутивы и другие операционные системы, основанные на ядре Linux, которые используют Upstart в качестве системы по умолчанию инициализации:

Upstart был впервые включен в Ubuntu в 6.10 (Edgy EFT) релиз в конце 2006 года, заменив Sysvinit. Ubuntu 9.10 (Karmic Koala) представил родное Upstart загрузочная как альфа 6.В свою очередь, после того, как проект Debian решил принять Systemd на будущем выпуске в 2014 году Марк Шаттлворт заявил, что Ubuntu начнет планы перейти на Systemd себя поддерживать согласованность с вверх по течению.

Upstart используется в Chrome OS от Google и Chromium OS.

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

Debian решил, что Systemd будет Система инициализации по умолчанию, начиная с выпуска Jessie, после рассмотрения перехода на Upstart. В конечном итоге было удалено из архива Debian в декабре 2015 года.
Ubuntu закончил переключатель Systemd в качестве системы инициализации по умолчанию в версии 15.04 (Vivid Vervet), за исключением Ubuntu Touch.
В Fedora 9, Upstart заменил Sysvinit, однако, Systemd заменил Upstart в релизе Fedora 15.
Red Hat включает в себя Upstart в их Red Hat Enterprise Linux 6 выпуска. В результате, она также используется RHEL 6 вариантов, таких как CentOS, Scientific Linux и Oracle Linux. Для RHEL 7, Systemd используется вместо.
OpenSUSE включены Upstart в версии 11.3 Milestone 4, но не по умолчанию. Systemd заменил Upstart, как система инициализации по умолчанию в OpenSUSE 12.1.
Upstart используется в WebOS компании HP для Palm Pre, Palm Pixi (как до, Palm, был выкуплен HP), HP Veer и HP Pre 3 смартфоны, наряду с планшета HP TouchPad.
Upstart заменил Sysvinit в Maemo 5 для Nokia интернет-планшетов и был сохранен для MeeGo на телефонах N9 и N950, несмотря на MeeGo перехода к Systemd после слияния с Moblin.

Процессы сервисов

Процесс сервиса использует конфигурационные файлы, которые позволяют запускать процессы в фоновом режиме.

Для примера попробуйте установить сервер Node.js.

Примечание: Node.js – это кроссплатформенная среда для серверных и сетевых приложений.

Node.js – очень лёгкий пакет, но по умолчанию он не установлен в Ubuntu 14.04. Чтобы установить его, введите:

Теперь попробуйте создать сервис. Для этого создайте новый файл nodetest.conf в каталоге /etc/init.

Примечание: Имя файла должно быть описательным.

Добавьте в файл описание и автора процесса:

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

Уровень запуска в сочетании с событием filesystem обеспечивает запуск процесса во время загрузки сервера.

Теперь нужно добавить в файл определённые ранее блоки. Поскольку это приложение является серверным, нужно добавить в конфигурации логирование. Чтобы регистрировать запуск и остановку приложения, используйте действия script, pre-start script и pre-stop script.

Как видите, pre-start и pre-stop – это состояния процессов, но их можно добавлять в блоки.

Сначала нужно добавить сам сценарий процесса. Он получит ID процесса для фонового сервера Node, а затем запустит сценарий приложения

Обратите внимание на отступы в блоке – они важны для корректного синтаксиса

Приложению Node необходима переменная домашнего каталога, потому /srv экспортируется в первой строке блока. Символы $$ устанавливают PID процесса и создают файл для него.

Теперь сосредоточьтесь на pre-start и pre-stop. Дата, а также сообщения о запуске и остановке процесса, будут внесены в лог:

Обратите внимание: блок pre-stop содержит строку, которая удаляет PID-файл. Эта задача будет частью процесса остановки

В результате файл будет иметь такой вид:

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

Как сказано в строке exec, сценарий Node.js будет запущен с сервера, потому нужно создать файл nodetest.js:

Полученный сценарий выполняет следующие действия:

Запрашивает HTTP-модуль Node.
Создаёт веб-сервер HTTP.
Provide a status 200 (OK) response in the Header
Возвращает фразу Hello World.
Прослушивает порт 8888.

При помощи следующего кода можно запустить приложение Node:

Сохранив файл, убедитесь, что в синтаксисе нет ошибок.

Убедившись, что код не содержит ошибок, перезапустите сервер и откройте ссылку:

На экране появится фраза Hello World.

Теперь нужно проверить, работает ли логирование. Откройте указанный в настройках лог и найдите в нём метки времени в строке Starting. После остановки сервиса в логе появится строка Stopping.

Для запуска стандартных команд (start, stop, restart и т.д.) используется следующий синтаксис:

Example Systemd service

/lib/systemd/system/foo.service:


Description=Job that runs the foo daemon
Documentation=man:foo(1)


Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}


WantedBy=multi-user.target

Outstanding Work

If you’d like to help out with the migration, take a look at …

Outstanding packages to convert:
- http://people.canonical.com/~jhunt/systemd/packages-to-convert/
  
  Note that the priority are the packages in «main».
blueprint: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration

… and then come and chat to us on #ubuntu-devel.

From a running system

Upstart

To switch to debug mode for the system init (PID 1):

  $ sudo initctl log-priority debug

To switch to debug mode for a session init (init PID != 1):

  $ initctl log-priority debug
  $ tail -f ~/.xsession-errors

Debian Packaging

Packages installing systemd services should build-depend on dh-systemd and either call dh --with systemd (if they use dh) or call dh_systemd_enable and dh_systemd_start before/after dh_installinit respectively. Files under debian called *.service will be installed analogously to *.upstart files. See dh_systemd_enable(1p) for how to customize the installation.

man systemd — «CONCEPTS» has an useful link collection to the per-topic pages
Ubuntu wiki systemd page (not relevant for porting)
Upstream systemd page with lots of documentation pointers
man 8 init, man 5 init (on an Upstart system)
systemd manpages for service writers:
Upstart

Upstart Cookbook

Традиционный init

Вообще, если попытаться описать процесс загрузки Linux в двух словах, то это будет звучать примерно так. После включения компьютера, загрузки ядра в память, монтирования корневой файловой системы, опроса и инициализации оборудования передача управления по дальнейшей загрузке ОС передается специальному демону, называемому init. Задача init — это запуск всех остальных процессов, нужных для корректного функционирования ОС. В принципе, при помощи параметра ядра init можно указать ядру запускать все, что нам заблагорассудится (что в некоторых специфических дистрибутивах Linux и сделано), однако практически во всех традиционных дистрибутивах запускается именно демон init. Идея на самом деле очень простая и классная. Зачем ядру заморачиваться над запуском хреновой тучи приложений, если достаточно позаботиться лишь о запуске одного процесса, который и будет разруливать дальнейшую загрузку/работу/остановку системы.

Традиционный демон init определяет 7 так называемых «уровней выполнения». Для каждого такого уровня должен быть определен вполне определенный набор системных служб, запускаемых во время загрузки, получающих команды во время работы и останавливаемых во время перезагрузки системы или выключения питания:

0 — система полностью прекратила работу
1 или S — однопользовательский режим
2…5 — многопользовательские режимы
6 — перезагрузка системы

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

После запуска, демон init читает конфигурацию из файла /etc/inittab и на основании этой конфигурации начинает уже, так сказать, непосредственную деятельность. Грубо говоря, в файле /etc/inittab содержатся указания о том, что должен делать демон init на каждом из уровней.

В какой-то момент формат файла /etc/inittab оказался слишком устаревшим и перестал обеспечивать требуемую разработчиками функциональность, после чего в Linux появился каталог /etc/init.d, содержащий в себе файл /etc/init.d/rc

shell-сценарии запускающие все необходимое, а файл /etc/initttab стал выполнять функцию хранилища номера уровня по-умолчанию и вызова файла /etc/init.d/rc при смене уровней работы системы.

В каталоге /etc/init.d находятся сценарии запуска/перезапуска/останова системных служб. Все эти сценарии могут вызываться с разнообразными параметрами, обязательными из которых являются параметры start и stop. Нужно вам, например, запустить сервер sshd — вы просто даете команду /etc/init.d/sshd start и shell-сценарий делает все необходимо для запуска сервиса. Нужно остановить? Пожалуйста: /etc/init.d/sshd stop. Сам демон init работает не напрямую со сценариями, а следующим образом.

Существует несколько каталогов /etc/rcX.d, где X — это номер уровня работы системы. В каждом из этих каталогов находятся символьные ссылки на сценарии из каталога /etc/init.d. Довольно удобно, поскольку если нужно будет внести изменения в скрипт, то только в одном месте.

Каждая ссылка в каталоге /etc/rcX.d имеет вид YNNname, где Y — определяет параметр, передаваемый скрипту, NN — двузначный номер, name — имя файла сценария работы со службой из каталога /etc/init.d. Y должна быть одной из букв S или K, соответственно определяя, start или stop передавать скрипту. NN — задает очередность выполнения скриптов. Таким образом, при переходе на другой уровень работы системы, init сперва выполняет все K-сценарии в соответствующем текущему уровню каталоге /etc/rcX.d и потом выполняет все S-сценарии в соответствующем уровню, на который переходит система, каталоге /etc/rcX.d.

Для переключения между различными уровнями работы системы существует утилита telinit, которая умеет сообщать демону init, на какой уровень нужно перейти.

Таким вот, в принципе, несложным образом и живет ОС Linux от запуска до остановки. Заранее прошу прощения за мой местами кривой стиль изложения материала. Всех заинтересовавшихся более подробно темой работы демона init отправляю к man-страницам init (8), inittab (5), telinit (8), runlevel (8).

Что такое Upstart и чем он лучше

Начиная с Ubuntu 6.10 старый добрый init был заменен более функционально-продвинутым аналогом, которое авторы назвали Upstart. Основной козырь Upstart в том, что его работа основана на событиях. Это означает, что, в отличие от init, Upstart запускает и останавливает задачи не просто вызывая соответствующие shell-скрипты, а еще и наблюдает за работой запущенных им задач, основываясь на событиях, получаемых им от приложений. Это дает возможность, например, перезапустить в случае чего внезапно упавшую службу самим демоном Upstart, а не возлагать это на какие-то потусторонние программы.

Прежде чем продолжать дальше, хочется отметить, что в терминологии Upstart существует два понятия: служба (service) и задача (task). Главное отлицие службы от задачи состоит в том, что служба перезапускается в случае внезапного ее завершения, а задача — нет. Краткий перечень основных возможностей Upstart, взятый на сайте проекта:

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

Из функционала, который только планируется в будущих версиях Upstart на сайте отметили следующие моменты:

генерация событий через определенный интервал времени или с использованием планировщика
генерация событий в ответ на изменение содержимого файлов/каталогов
наблюдение и перезапуск демонов процессы которых отделены от родительских
возможность непривилегированным пользователям создавать свои собственные службы и управлять ими
связь с демоном init средствами DBUS

start on и stop on

Данная запись позволяет вам указать, при возникновении каких именно событий должно выполняться или останавливаться ваше задание.

Самое первое событие, которое генерирует Upstart — это событие startup. Данное событие происходит в тот момент, когда корневая файловая система еще не доступна для записи и отсутствует поддержка сети.

В случае с заданиями из архива с примерами, имеется также событие runlevel X, где X может быть числом от 1 до 6 или символом S. При генерации таких событий будут выполняться init-скрипты, соответствующие уровню запуска X.

И, наконец, вы можете управлять своими заданиями на основе событий, возникающих, в процессе запуска/останова других заданий. Для этого вы можете использовать события stopped и started.

Для определения событий, по которым ваше задание должно запускаться используйте запись start on, останавливаться — stop on. Все просто!

start on startup
start on runlevel 2
start on runlevel 3
start on stopped rcS
start on started tty1

Overview

Project is in maintaince mode only. No new features are being developed and the
general advice would be to move over to another minimal init system or systemd.

Upstart is an event-based replacement for the daemon
which handles starting of tasks and services during boot, stopping them
during shutdown and supervising them while the system is running.

It was originally developed for the Ubuntu
distribution, but is intended to be suitable for deployment in all
Linux distributions as a replacement for the venerable System-V init.

Most major users of Upstart have moved on. Commercial and security support for upstart
will stop be from Canonical once the last Ubuntu release shipping upstart lapses.

Project is in maintaince mode only. No new features are being developed and the
general advice would be to move over to another minimal init system or systemd.

Feature Highlights

Tasks and Services are started and stopped by events
Events are generated as tasks and services are started and stopped
Events may be received from any other process on the system
Services may be respawned if they die unexpectedly
Supervision and respawning of daemons which separate from their parent
process
Communication with the init daemon over D-Bus
User services, which users can start and stop themselves

Known Users

Ubuntu
- Introduction: 6.10
- upstart as system init — last release — 14.04 LTS, public support ending April 2019
- upstart as user init — last release — 16.04 LTS, public support ending April 2021
Fedora introduced in 9. Removed in 15.
Red Hat Enterprise Linux 6
Nokia’s Maemo platform
Palm’s WebOS
Google’s Chromium OS
Google’s Chrome OS

Переназначение файлов

Переназначенные файлы — это файлы, размещённые в каталоге конфигураций задач («») и заканчивающиеся на «».
Эти файлы позволяют менять поведение задачи не изменяя оригинальный файл конфигурации.
Файлы переназначения имеют такой-же синтаксис, как и файлы конфигурации задач («.conf»).

Например, сделать так, чтобы сервис никогда не запускался автоматически:

  echo manual >> /etc/init/myjob.override

Вернуть первоначальное поведение можно удалив файл переназначения.

Другой пример: изменить условие запуска задачи:

  echo "start on (starting job-A or event-B)" >> /etc/init/myjob.override

Обратите внимание, что файлы переназначения не обрабатываются, если не найден соответствующий файл конфигурации задачи.

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

Permanent switch back to upstart

Install the upstart-sysv package, which will remove ubuntu-standard and systemd-sysv (but should not remove anything else — if it does, yell!), and run sudo update-initramfs -u. After that, grub’s «Advanced options» menu will have a corresponding «Ubuntu, with Linux … (systemd)» entry where you can do an one-time boot with systemd.

If you want to switch back to systemd, install the systemd-sysv and ubuntu-standard packages.

High-level startup concept

Upstart’s model for starting processes (jobs) is «greedy event-based», i. e. all available jobs whose startup events happen are started as early as possible. During boot, upstart synthesizes some initial events like startup or rcS as the «tree root», the early services start on those, and later services start when the former are running. A new job merely needs to install its configuration file into /etc/init/ to become active.

systemd’s model for starting processes (units) is «lazy dependency-based», i. e. a unit will only start if and when some other starting unit depends on it. During boot, systemd starts a «root unit» (default.target, can be overridden in grub), which then transitively expands and starts its dependencies. A new unit needs to add itself as a dependency of a unit of the boot sequence (commonly multi-user.target) in order to become active.

Job vs. unit keywords

This maps the keywords that can occur in an upstart job to the corresponding ones in a systemd unit. Keywords which don’t have a direct equivalent are marked with «-«.

Upstart stanza	systemd unit file directive	systemd unit file section	Notes
`apparmor load`	`AppArmorProfile`		Available in systemd version 210 and later
`apparmor switch`	—
`author`	—
`chdir`	`WorkingDirectory`	Service
`chroot`	`RootDirectory`
`console output`	`StandardOutput=tty`, `StandardError=tty`
`console owner`	`StandardOutput=tty`, `StandardError=tty`		No real equivalent?
`console none`	`StandardOutput=null`, `StandardError=null`
`description`	`Description`	Unit
`env`	`Environment`, `EnvironmentFile`	Service
`exec`	`ExecStart`	Service
`expect fork`	`Type=forking`	Unit
`expect daemon`	`Type=forking`	Unit
`expect stop`	`Type=notify`	Unit	Similar, not equivalent. Requires daemon to link to `libsystemd-daemon` and call sd_notify().
`instance`	Use «`%I`» and «`%i`» in `ExecStart`, etc to specify an instance		See `/lib/systemd/system/getty@.service` for an example
`kill signal`	`KillSignal`
`kill timeout`	`TimeoutStopSec`
`limit as`	`LimitAS`
`limit core`	`LimitCORE`
`limit cpu`	`LimitCPU`
`limit data`	`LimitDATA`
`limit fsize`	`LimitFSIZE`
`limit memlock`	`LimitMEMLOCK`
`limit msgqueue`	`LimitMSGQUEUE`
`limit nice`	`LimitNICE`
`limit nofile`	`LimitNOFILE`
`limit nproc`	`LimitNPROC`
`limit rss`	`LimitRSS`
`limit rtprio`	`LimitRTPRIO`
`limit sigpending`	`LimitSIGPENDING`
`limit stack`	`LimitSTACK`
`manual`	No directive(?) — use `systemctl disable foo.service`
`nice`	`Nice`	Unit
`normal exit`	`SuccessExitStatus`
`oom score`	`OOMScoreAdjust`
`post-start exec/script`	`ExecStartPost`	Service
`post-stop exec/script`	`ExecStopPost`	Service
`pre-start exec/script`	`ExecStartPre`	Service
`pre-stop`	—
`reload signal`	`ExecReload=/bin/kill -SIGFOO $MAINPID`	Service
`respawn`	`Restart=on-failure`	Service
`respawn limit`	`RestartSec`
`script`/`end script`	See shell scripts below
`setgid`	`Group`	Service
`setuid`	`User`	Service
`start on`	`Wants`, `Requires`, `Before`, `After`	Unit
`stop on`	`Conflicts`, `BindsTo` (but not commonly used)	Unit
`task`	`Type=oneshot`	Unit
`umask`	`UMask`	Unit
`usage`	`Documentation`	Unit	no direct equivalent
`version`	—

Shell scripts

systemd does not provide special support for shell scripts (by design). For short shell commands you can use something like

   ExecStart=/bin/sh -ec 'echo hello'

Longer scripts are usually program logic and should not be directly in a conffile and duplicated between upstart and systemd; factor it out in a proper script in e. g. /usr/share/myapp/ and call it from both the upstart job and the systemd unit.

Automatic starting

As described above, services which want to start during boot (i. e. are not activated through sockets, D-BUS, or similar) need to become a dependency of an existing boot target. Those need an section with a WantedBy= that specifies the unit which that new service wants to become a dependency of (see man systemd.unit). Very commonly this is multi-user.target, which is roughly equivalent to start on runlevel in upstart; see man systemd.special for other common targets.

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

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

Я описывал в своих статьях процесс создания скриптов для systemD/Upstart и сейчас я хотел бы написать о написании init скриптов. Тема не новая и используется давно, но я большую часть своих тем беру именно из черновиков, которые накопились за года 3-4. У меня не хватает времени на все публикации + наполнять контент максимально (по крайней мере, сразу) и по этому, имеет что имеем. Но не смотря на это, у меня уже довольно много читателей — и это хорошо, это радует!

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

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

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

Состояние процессов и события

Процессы системы хранятся в каталоге /etc/init/, а процессы пользователей – в каталоге ~/.init/.

Рабочие процессы пользователей запускаются в их сессиях. Такие процессы не являются общесистемными.

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

Каждая такая задача имеет целью запуск (start) или остановку (stop). Между этими двумя целями находится ряд состояний задачи, который определяет текущее действие процесса в зависимости от цели.

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

Процесс в состоянии post-start считается запущенным процессом. Он остаётся запущенным до состояния pre-stop, в котором он готовится к остановке. После этого процесс останавливается и переходит в состояние post-stop (очистка системы).

Чтобы увидеть, как процесс изменяет свои состояния, переведите приоритет лога Upstart (/var/log/upstart/) в debug:

Обратите внимание: состояния и события – не одно и то же

Getting Started

Once you’ve downloaded and unpacked upstart, you
will need to configure the source tree, build and install it. The main
question here is deciding whether or not you want to take the plunge and
replace immediately, or whether you want to test first.

The brave will want to configure the source such that the executable parts
are placed on the root filesystem and the data parts (man pages, etc.) are
in the usual places.

./configure --prefix=/usr --exec-prefix= --sysconfdir=/etc

Everyone else will prefer to install it under an alternate prefix like
. You will need to boot with an alternate
kernel command-line such as .

./configure --prefix=/opt/upstart --sysconfdir=/etc

Job Definitions

Don’t reboot just yet, you haven’t configured anything to be started so
your machine will just sit there. You need to write some job definitions
that instruct upstart what to do, and when.

Upstart comes with a set of default jobs which it installs into
. These are based on the
configuration of Debian-based systems, including running the
script.

This is recommended, as it allows you to boot your machine normally, as well
as support existing applications, while you convert things to using upstart
jobs.

The defaults will probably need modification to work in your distribution,
as paths and maybe even arguments will need to be changed to match. Your
existing should be a useful guide.

Once happy, place the files in and now you’re
ready to reboot and use upstart.

Обоснование

Традиционный процесс инициализации изначально был ответственен только за компьютер в нормальном рабочем состоянии после включения питания, или предотвращал закрытие услуги перед отключением. В результате, конструкция строго синхроннизировалась, блокируя будущие задачи, пока текущая не завершена. Задачи программы также должны быть определены заранее, так как они ограничивают этим подготовительную стадию или очистку функции. Это оставляет его не в состоянии обрабатывать различные не Startup-задачи на современном настольном компьютере, в том числе:

Добавление или удаление USB флэш-накопителей и других портативных хранения / сетевых устройств, в то время как компьютер работает.
Обнаружение и сканирование новых устройств хранения данных, без блокировки системы, особенно, когда диск не может считываться даже без питания до тех пор, пока не будет сканироваться.
Загрузка прошивки для устройства, которое может потребоваться произойти после того, как оно было обнаружено, но прежде, чем она может использоваться.

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

Примеры Init скрипта

Приведу наглядный пример запуска томката.

Запуск TOMCAT с init

Создадим init скрипт для запуска:

# vim /etc/init.d/tomcat9

И приводим к виду:

#!/bin/bash -x
#
# Provides:          tomcat9
# Required-Start:    $local_fs $remote_fs $network
# Required-Stop:     $local_fs $remote_fs $network
# Should-Start:      $named
# Should-Stop:       $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start Tomcat.
# Description:       Start the Tomcat servlet engine.
### END INIT INFO

export CATALINA_HOME=/usr/local/tomcat9
export JAVA_HOME=/usr/local/jdk1.8.0_131
export PATH=$JAVA_HOME/bin:$PATH

service_name="tomcat9"

start() {
 echo "Starting Tomcat 9..."
 /bin/su -s /bin/bash tomcat -c $CATALINA_HOME/bin/startup.sh
}
stop() {
 echo "Stopping Tomcat 9..."
 /bin/su -s /bin/bash tomcat -c $CATALINA_HOME/bin/shutdown.sh
}
status() {
 if (( $(ps -ef | grep -v grep | grep $service_name | wc -l) > 0 )); then
     echo "$service_name is running!!!"
 else
     echo "$service_name is down!!!"
 fi
}
case $1 in
  start|stop|status) $1;;
  restart) stop; start;;
  *) echo "Usage : $0 <start|stop|restart>"; exit 1;;
esac

exit 0

Даем права на запуск (на исполнение):

# chmod 755 /etc/init.d/tomcat9

ИЛИ:

# chmod +x /etc/init.d/tomcat9

Запускаем томкат:

# service tomcat9 start

Открываем браузер и смотрим что вышло!

Вот еще один скрипт:

#!/bin/bash -x

DAEMON_PATH="/home/wes/Development/projects/myapp"

DAEMON=myapp
DAEMONOPTS="-my opts"

NAME=myapp
DESC="My daemon description"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

case "$1" in
start)
	printf "%-50s" "Starting $NAME..."
	cd $DAEMON_PATH
	PID=`$DAEMON $DAEMONOPTS > /dev/null 2>&1 & echo $!`
	#echo "Saving PID" $PID " to " $PIDFILE
        if ; then
            printf "%s\n" "Fail"
        else
            echo $PID > $PIDFILE
            printf "%s\n" "Ok"
        fi
;;
status)
        printf "%-50s" "Checking $NAME..."
        if ; then
            PID=`cat $PIDFILE`
            if ; then
                printf "%s\n" "Process dead but pidfile exists"
            else
                echo "Running"
            fi
        else
            printf "%s\n" "Service not running"
        fi
;;
stop)
        printf "%-50s" "Stopping $NAME"
            PID=`cat $PIDFILE`
            cd $DAEMON_PATH
        if ; then
            kill -HUP $PID
            printf "%s\n" "Ok"
            rm -f $PIDFILE
        else
            printf "%s\n" "pidfile not found"
        fi
;;

restart)
  	$0 stop
  	$0 start
;;

*)
        echo "Usage: $0 {status|start|stop|restart}"
        exit 1
esac

Подойдет к большинству скриптов, а для остальных — можно отредактировать немного.

И, вот еще полезный довольно вариант:

#!/bin/sh
### BEGIN INIT INFO
# Provides:
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

dir=""
cmd=""
user=""

name=`basename $0`
pid_file="/var/run/$name.pid"
stdout_log="/var/log/$name.log"
stderr_log="/var/log/$name.err"

get_pid() {
    cat "$pid_file"
}

is_running() {
     && ps -p `get_pid` > /dev/null 2>&1
}

case "$1" in
    start)
    if is_running; then
        echo "Already started"
    else
        echo "Starting $name"
        cd "$dir"
        if ; then
            sudo $cmd >> "$stdout_log" 2>> "$stderr_log" &
        else
            sudo -u "$user" $cmd >> "$stdout_log" 2>> "$stderr_log" &
        fi
        echo $! > "$pid_file"
        if ! is_running; then
            echo "Unable to start, see $stdout_log and $stderr_log"
            exit 1
        fi
    fi
    ;;
    stop)
    if is_running; then
        echo -n "Stopping $name.."
        kill `get_pid`
        for i in 1 2 3 4 5 6 7 8 9 10
        # for i in `seq 10`
        do
            if ! is_running; then
                break
            fi

            echo -n "."
            sleep 1
        done
        echo

        if is_running; then
            echo "Not stopped; may still be shutting down or shutdown may have failed"
            exit 1
        else
            echo "Stopped"
            if ; then
                rm "$pid_file"
            fi
        fi
    else
        echo "Not running"
    fi
    ;;
    restart)
    $0 stop
    if is_running; then
        echo "Unable to stop, will not attempt to start"
        exit 1
    fi
    $0 start
    ;;
    status)
    if is_running; then
        echo "Running"
    else
        echo "Stopped"
        exit 1
    fi
    ;;
    *)
    echo "Usage: $0 {start|stop|restart|status}"
    exit 1
    ;;
esac

exit 0

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

Установка UpStart

Графическая установка

https://youtube.com/watch?v=xiJSfPrRl14

Первым делом, проверяем, соответствует ли наша система требованиям:

Linux >= 2.6.17
GCC >= 4.1
glibc >= 2.4

Конфигурируем исходный код для компиляции:

О дополнительных возможных параметрах конфигурирования можно узнать из файла INSTALL, находящегося непосредственно в корне дерева исходных кодов.

Собираем: make

Устанавливаем: make install

Описание заданий

После успешной установки Upstart, необходимо создать определения заданий для того, чтобы система смогла загрузиться. Другими словами, задания как раз есть, что чем оперирует Upstart в своей работе. Чтобы быстрей понять, как это все делается и, так сказать, увидеть своими глазами, можно скачать архив примеров заданий. Возможно, вам придется их немного видоизменить для корректной работы с вашей системой, однако все необходимое для начальной конфигурации системы и успешного первого запуска в архиве примеров есть. Все примеры необходимо распаковать в каталог /etc/event.d. Именно из него Upstart берет все необходимое для работы (про /etc/inittab все дружно забыли). За исключением моментов описанных в разделе «Upstart on Other Distributions» все скрипты в каталогах /etc/rcX.d можно оставить без изменений. все должно заработать.

Последний штрих и перезагрузка

Когда все готово, можно попробовать перегрузить Linux и посмотреть, что у вас получилось. Перед перезагрузкой не забудьте проверить значение параметра init, передаваемого ядру вашим загрузчиком, в случае, если Upstart установил исполняемый файл init в отличный от /sbin каталог. Вообще, в принципе, настоятельно рекомендуется для начала не заменять стандартный sysvinit на init Upstart, а установить его в какой-то другой каталог и при помощи параметра ядра init сперва все тщательно протестировать.

Пишем задания

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

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

Имена файлов должны соответствовать именам заданий и сами файлы не должны быть исполняемыми.

Все задания помещаются в файлы, расположенные в каталоге . Имена файлов должны соответствовать именам заданий и сами файлы не должны быть исполняемыми.

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

Boot Time

Remove the following from the kernel command-line via the grub menu:

«quiet»
«splash»

Upstart

Add «--debug to the kernel command-line via the grub menu.
Optionally add «console=ttyS0 to the kernel command-line via the grub menu if you have a serial console.

systemd

Add «systemd.log_level=debug to the kernel command-line via the grub menu.
Optionally add one of the following too:
- «systemd.log_target=kmsg»
- «systemd.log_target=console»

Starting a rescue shell

Run:
$ sudo systemctl enable debug-shell.service
Reboot.
If the system fails to boot, you can now switch to tty9 (CTRL+ALT+F9) for a getty console login.

exec и script

Каждое задание обязано иметь запись script или exec. Эта запись определяет способ запуска задания. exec используется в случае, когда вы запускаете какую-то программу с вашей файловой системы с возможностью передачи дополнительных параметров вызываемой программе.

exec /bin/foo --opt -xyz foo bar

Запись script используется для вставки bash-кода непосредственно в файл задания. Все, что вы здесь укажете, будет выполнено стандартным интерпретатором /bin/sh с параметром -e, таким образом позволяя прервать скрипт в случае неправильного использования любой команды. Запись script должна заканчиваться строкой «end script».

script
# do some stuff
if ; then
...
fi
end script

/etc/default files which enable/disable jobs

enable=1|0 type settings in /etc/default files should generally be avoided. The canonical way to enable/disable a service in an init system agnostic way is update-rc.d <service> enable|disable, which will translate to init system specific actions such as adding/removing symlinks (SysV and systemd) or creating/removing job override files (upstart). For systemd in particular, admins also often call systemctl enable|disable <service> directly. Thus these settings are redundant in /etc/default.

There is no clean way to evaluate these in a systemd unit. You can check them in ExecStartPre=, but that would mean that the unit will be in «failed» state if the service gets disabled that way, and so, is not desirable.

For these reasons (confusing/duplication/cannot be modelled in systemd), these settings should be removed. This was done in whoopsie 0.2.42, you can check its diff for a transition which respects the old default setting and removes it on upgrade.