Systemd – это система инициализации и системный менеджер, который становится новым стандартом для Linux-машин. Споры о продуктивности systemd по сравнению с традиционными системами инициализации SysV ведутся до сих пор, тем не менее, эту систему планируют внедрить большинство дистрибутивов, а многие уже сделали это.

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

Данный мануал научит вас работать с командой systemctl, главным инструментом управления системы инициализации systemd. Вы узнаете, как управлять сервисами, проверять состояние и работать с конфигурационными файлами.

Управление сервисами

Основная цель init-системы – инициализировать компоненты, которые должны запускаться после загрузки ядра Linux (традиционно они называются «пользовательскими» компонентами). Система инициализации также используется для управления сервисами и демонами сервера. Имея это в виду, начнем знакомство с systemd с простых операций управления сервисами.

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

Для задач управления сервисами предназначены юнит-файлы с суффиксом.service. Однако в большинстве случаев суффикс.service можно опустить, так как система systemd достаточно умна, чтобы без суффикса определить, что нужно делать при использовании команд управления сервисом.

Запуск и остановка сервиса

Чтобы запустить сервис systemd, используйте команду start. Если вы работаете не в сессии пользователя root, вам нужно использовать sudo, поскольку эта команда повлияет на состояние операционной системы:

sudo systemctl start application.service

Как уже говорилось ранее, systemd знает, что для команд управления сервисами нужно искать файлы *.service, поэтому эту команду можно ввести так:

sudo systemctl start application

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

Чтобы остановить сервис, достаточно ввести команду stop:

sudo systemctl stop application.service

Перезапуск и перезагрузка

Чтобы перезапустить сервис, используйте restart:

sudo systemctl restart application.service

Если указанное приложение может перезагрузить свои конфигурационные файлы (без перезапуска), можно использовать reload:

sudo systemctl reload application.service

Если вы не знаете, может ли сервис перезагрузить свои файлы, используйте команду reload-or-restart. Она перезагрузит сервис, а если это невозможно – перезапустит его.

sudo systemctl reload-or-restart application.service

Включение и отключение сервисов

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

Для этого существует команда enable:

sudo systemctl enable application.service

Это создаст символическую ссылку на копию файла сервиса (обычно в /lib/systemd/system или /etc/systemd/system) в точке на диске, где systemd ищет файлы для автозапуска (обычно /etc/systemd/system/some_target.target.want, подробнее об этом — дальше в руководстве).

Чтобы убрать сервис из автозагрузки, нужно ввести:

sudo systemctl disable application.service

Имейте в виду, что включение сервиса не запускает его в текущей сессии. Если вы хотите запустить сервис и включить его в автозагрузку, вам нужно запустить команды start и enable.

Проверка состояния сервиса

Чтобы проверить состояние сервиса, введите:

systemctl status application.service

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

Например, при проверке состояния сервера Nginx вы можете увидеть такой вывод:

nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd: Started A high performance web server and a reverse proxy server.

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

Существуют также методы проверки конкретных состояний. Например, чтобы проверить, активен ли данный юнит (запущен ли он), вы можете использовать команду is-active:

systemctl is-active application.service

Это отобразит текущее состояние юнита, обычно это active или inactive. Код завершения будет «0», если юнит активен, что упрощает процесс анализа.

Чтобы узнать, включен ли юнит, вы можете использовать команду is-enabled:

systemctl is-enabled application.service

Эта команда сообщит, включен ли сервис, и снова определит код завершения как «0» или «1» в зависимости от результата.

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

systemctl is-failed application.service

Команда вернет active, если юнит работает правильно, и failed, если случилась ошибка. Если юнит был остановлен намеренно, команда может вернуть unknown или inactive. Код завершения «0» означает, что произошел сбой, а «1» указывает на любое другое состояние.

Обзор состояния системы

Ранее мы рассмотрели команды, необходимые для управления отдельными сервисами, но они не очень полезны для изучения текущего состояния системы. Существует несколько команд systemctl, которые предоставляют эту информацию.

Просмотр списка текущих юнитов

Чтобы запросить список текущих юнитов systemd, используйте команду list-units:

systemctl list-units

Эта команда покажет список всех юнитов, которые в настоящее время существуют в системе systemd. Результат будет выглядеть примерно так:

UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dcron.service loaded active running Periodic Command Scheduler
dkms.service loaded active exited Dynamic Kernel Modules System
[email protected] loaded active running Getty on tty1
. . .

В выводе есть такие столбцы:

UNIT – название юнита systemd.
LOAD – сообщает, была ли конфигурация юнита обработана systemd. Конфигурация загруженных юнитов хранится в памяти.
ACTIVE – сводное состояние юнита. Обычно это позволяет быстро определить, успешно ли запущен текущий юнит.
SUB: состояние более низкого уровня, которое сообщает подробную информацию об устройстве. Это часто зависит от типа юнита, состояния и фактического метода, в котором запущен юнит.
DESCRIPTION – краткое описание функций юнита.

Поскольку команда list-units показывает по умолчанию только активные юниты, все вышеперечисленные записи будут показывать loaded в столбце LOAD и active в столбце ACTIVE. Такой формат является поведением systemctl по умолчанию при вызове без дополнительных команд, поэтому вы увидите то же самое, если вы вызываете systemctl без аргументов:

С помощью systemctl можно запрашивать различную информацию путем добавления флагов. Например, чтобы увидеть все юниты, которые загрузила (или попыталась загрузить) система systemd, независимо от того, активны ли они в данный момент, вы можете использовать флаг -all:

systemctl list-units --all

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

Вы можете использовать другие флаги для фильтрации результатов. Например, флаг —state= можно использовать для определения состояний LOAD, ACTIVE или SUB. Флаг —all нужно оставить, чтобы система отображала неактивные юниты:

systemctl list-units --all --state=inactive

Еще один популярный фильтр – это —type=. Он позволяет отфильтровать юниты по типу. К примеру, чтобы запросить только активные юниты, можно ввести:

systemctl list-units --type=service

Список юнит-файлов

Команда list-units отображает только юниты, которые система systemd попыталась обработать и загрузить в память. Поскольку systemd избирательно читает только те юнит-файлы, которые кажутся ей необходимыми, список не будет включать все доступные юнит-файлы. Чтобы просмотреть список всех доступных юнит-файлов (включая те, что systemd не пыталась загрузить), используйте команду list-unit-files.

systemctl list-unit-files

Юниты являются представлениями ресурсов, о которых знает systemd. Поскольку systemd не обязательно читает все определения юнитов, она представляет только информацию о самих файлах. Вывод состоит из двух столбцов: UNIT FILE и STATE.

UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
. . .

Обычно столбец STATE содержит значения enabled, disabled, static или masked. В этом контексте static означает, что в юнит-файле нет раздела install, который используется для включения юнита. Таким образом, эти юниты невозможно включить. Обычно это означает, что юнит выполняет одноразовое действие или используется только как зависимость другого юнита и не должен запускаться сам по себе.

Управление юнитами

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

Отображение юнит-файла

Чтобы отобразить юнит-файл, который загрузила systemd, вы можете использовать команду cat (была добавлена в версии systemd 209). Например, чтобы увидеть юнит-файл демона планирования atd, можно ввести:

systemctl cat atd.service
Description=ATD daemon
Type=forking
ExecStart=/usr/bin/atd
WantedBy=multi-user.target

На экране вы увидите юнит-файл, который известен текущему запущенному процессу systemd. Это может быть важно, если вы недавно изменяли файлы модулей или если вы переопределяете некоторые параметры в фрагменте юнит-файла (об этом поговорим позже).

Отображение зависимостей

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

systemctl list-dependencies sshd.service

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

sshd.service
├─system.slice
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
. . .

Рекурсивные зависимости отображаются только для юнитов.target, которые указывают состояния системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг —all.

Чтобы показать обратные зависимости (юниты, зависящие от указанного элемента), вы можете добавить в команду флаг —reverse. Также полезными являются флаги —before и —after, они отображают юниты, которые зависят от указанного юнита и запускаются до или после него.

Проверка свойств юнита

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

systemctl show sshd.service
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .

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

systemctl show sshd.service -p Conflicts
Conflicts=shutdown.target

Маскировка юнитов

Systemd может блокировать юнит (автоматически или вручную), создавая симлинк на /dev/null. Это называется маскировкой юнитов и выполняется командой mask:

sudo systemctl mask nginx.service

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

Если вы проверите list-unit-files, вы увидите, что сервис отмечен как masked:

systemctl list-unit-files
. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
. . .

Если вы попробуете запустить сервис, вы получите такое сообщение:

sudo systemctl start nginx.service
Failed to start nginx.service: Unit nginx.service is masked.

Чтобы раскрыть (разблокировать) юнит и сделать его доступным, используйте unmask:

sudo systemctl unmask nginx.service

Это вернет сервис в его прежнее состояние.

Редактирование юнит-файлов

Хотя конкретный формат юнит-файлов не рассматривается в данном руководстве, systemctl предоставляет встроенные механизмы для редактирования и изменения юнит-файлов. Эта функциональность была добавлена в systemd версии 218.

Команда edit по умолчанию открывает сниппет юнит-файла:

sudo systemctl edit nginx.service

Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение юнита. В каталоге /etc/systemd/system будет создан каталог, который содержит имя устройства с суффиксом.d. Например, для nginx.service будет создан каталог nginx.service.d.

Внутри этого каталога будет создан сниппет с именем override.conf. Когда юнит загружается, systemd объединит в памяти сниппет для переопределения с остальным юнит-файлом. Директивы сниппета будут иметь приоритет над теми, что указаны в исходном юнит-файле.

Если вы хотите отредактировать весь юнит-файл вместо создания сниппета, вы можете передать флаг —full:

sudo systemctl edit --full nginx.service

Это загрузит текущий юнит-файл в редактор, где его можно будет изменить. Когда редактор закроется, измененный файл будет записан в /etc/systemd/system и будет иметь приоритет над определением юнита системы (обычно он находится где-то в /lib/systemd/system).

Чтобы удалить все сделанные вами дополнения, удалите каталог конфигурации.d или измененный файл сервиса из /etc/systemd/system. Например, чтобы удалить сниппет, можно ввести:

sudo rm -r /etc/systemd/system/nginx.service.d

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

sudo rm /etc/systemd/system/nginx.service

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

sudo systemctl daemon-reload

Изменение уровней запуска

Цели – это специальные юнит-файлы, которые описывают уровни системы или точки синхронизации. Как и другие юниты, файлы целей можно определить по суффиксу. В данном случае используется суффикс.target. Сами по себе цели ничего не делают, вместо этого они используются для группировки других юнитов.

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

Например, есть цель swap.target, которая используется для того, что чтобы сообщить, что swap готов к использованию. Юниты, которые являются частью этого процесса, могут синхронизироваться с этой целью при помощи директив WantedBy= или RequiredBy=. Юниты, которым нужен своп, могут указывать это условие через спецификации Wants=, Requires= или After=.

Проверка и настройка целей по умолчанию

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

systemctl get-default
multi-user.target

Если вы хотите установить другую цель по умолчанию, вы можете использовать set-default. Например, если у вас установлен графический рабочий стол и вы хотите, чтобы система загружала его по умолчанию, вы можете соответствующим образом изменить цель:

sudo systemctl set-default graphical.target

Список доступных целей

Просмотреть список доступных целей можно с помощью команды:

systemctl list-unit-files --type=target

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

systemctl list-units --type=target

Изоляция целей

Можно запустить все юниты, связанные с целью, и остановить все юниты, которые не являются частью дерева зависимостей. Для этого используется команда isolate. Она похожа на изменение уровня запуска в других системах инициализации.

Например, если вы работаете в графической среде, где активна цель graphical.target, вы можете отключить графическую систему и перевести систему в состояние многопользовательской командной строки, изолировав multi-user.target. Поскольку graphical.target зависит от multi-user.target, но не наоборот, все графические юниты будут остановлены.

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

systemctl list-dependencies multi-user.target

Если вас все устраивает, можете изолировать цель:

sudo systemctl isolate multi-user.target

Сокращения

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

К примеру, чтобы перевести систему в режим отладки, можно ввести просто rescue вместо isolate rescue.target:

sudo systemctl rescue

Это обеспечит дополнительную функциональность – оповестит всех пользователей системы о событии.

Чтобы остановить систему, вы можете использовать команду halt:

sudo systemctl halt

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

sudo systemctl poweroff

Перезапуск можно начать с помощью команды reboot:

sudo systemctl reboot

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

Например, чтобы перезагрузить систему, вы можете ввести просто:

Заключение

Теперь вы знакомы с основными механизмами systemctl и знаете, как управлять системой инициализации с помощью этого инструмента.

Хотя systemctl работает в основном с процессом systemd, в системе systemd есть другие компоненты, которые контролируются другими утилитами. К примеру, для управления логированием и пользовательскими сеансами используются отдельные демоны и утилиты (journald/journalctl и logind/loginctl соответственно).

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

Systemd: быстрее света

Схема загрузки типичного Linux-дистрибутива выглядит примерно так: ядро инициализирует железо и запускает процесс /sbin/init, который, в свою очередь, запускает инициализационные скрипты. Скрипты монтируют файловые системы, настраивают сеть, различные устройства и начинают последовательный запуск демонов: syslogd, cron, cups и прочих, которые перечислены в конфигурационных файлах. В самом конце init запускает менеджер входа в систему: getty или xdm (kdm, gdm). Просто и логично, не так ли? Однако такая схема довольно примитивна, а в сравнении с Windows и Mac OS X так и вообще архаична. Их системы инициализации запускают задачи параллельно, не дожидаясь завершения одной, чтобы передать управление следующей. Если одна из них застопоривается на операции ввода-вывода, управление сразу получает другая, так что общее время загрузки сокращается, да так существенно, что традиционная система оказывается далеко позади.

В мире Linux так ведет себя только Ubuntu, да и то только последние два года. Все остальные продолжают по старинке последовательно грузить систему или используют самосборные костыли, которые распараллеливают процесс загрузки неумело и часто ошибочно (Gentoo и Arch, привет!). По-настоящему универсальное решение не найдено до сих пор, поэтому над идеей параллельной системы инициализации работают многие программисты.

Леннарт Поттеринг, сотрудник Red Hat и автор PulseAudio, один из них. Его последнее достижение - демон systemd, очередной претендент на звание убийцы /sbin/init, мимо которого можно было бы спокойно пройти, если бы идея, заложенная в его основу, не оказалась столь интересной и правильной.

Systemd отличается от любой другой системы инициализации тем, что намеренно делает сложные вещи простыми. 99% всех остальных параллельных систем инициализации провалились просто потому, что в сравнении с простым и понятным даже дикарю /sbin/ init они выглядели тяжеловесными монстрами. Чтобы обеспечить возможность параллельного запуска, не введя ОС в противоречивое состояние (которое может возникнуть, если, например, пытаться настроить сеть до загрузки сетевых драйверов или запустить демоны, не смонтировав нужную ФС), использовались различные методы синхронизации. В основном это были своеобразные «метки зависимостей», которые не давали очередному шагу инициализации отработать, если не был пройден шаг, описанный в его зависимостях.
Например, cron зависит от syslog, потому что ему надо вести логи; syslog зависит от настойки сети, потому что он способен принимать логи от удаленных машин и так далее. Из-за этого инициализационные скрипты превращались в запутанную вереницу блоков, а их составление значительно усложнялось. Systemd организован намного проще, он не следит за зависимостями, а просто запускает все, что есть, одновременно.

Я не шучу. Systemd использует механизмы контроля зависимостей только на самых ранних этапах инициализации, которые так или иначе должны происходить последовательно (монтирование корневой файловой системы, подключение swap, загрузка модулей и так далее). Когда же дело доходит до демонов, на запуск которых уходит 90% всего времени инициализации ОС, systemd забывает о зависимостях и стартует их всех сразу, показывая просто потрясающую скорость.

Это работает благодаря тому, что systemd знает об особенности работы демонов и их связи между собой.

Ведь на самом деле демонам нужны вовсе не другие демоны, а только «коммуникационные каналы», обеспечивающие обмен данными: cron не зависит от syslog, ему нужен сокет /dev/log, в который он сможет записывать свои логи, это же справедливо и в отношении любого другого демона. Все они общаются через сокеты, и единственная причина, почему демон A должен быть запущен раньше демонов B, C и D, заключается в том, что демон A должен создать сокет, который им нужен. Systemd учитывает эту особенность, поэтому его механизм параллельного запуска основан на сокетах, которые он создает для каждого демона заблаговременно, а затем запускает демоны одновременно. При этом ответственность за синхронизацию и «отслеживание зависимостей» теперь перекладываются на ядро, в рамках которого и реализован механизм сокетов.

Если, например, cron получит управление раньше syslog, ничего страшного не произойдет - cron найдет свой любимый /dev/log и даже сможет писать в него сообщения (если захочет, конечно), которые будут, нет, не выброшены, а буферизированы в сокете, но только до тех пор, пока cron не захочет записать в сокет сообщение, способное его переполнить. В этом случае ядро заблокирует процесс cron и передаст управление следующему процессу в очереди на исполнение (следующему демону). Вскоре (а может быть и сразу) очередь дойдет и до syslog, который запустится, прочитает сообщения, скопившиеся в /dev/log, обработает их и сам на чем-нибудь заблокируется (либо истратит отведенное ему время), и управление перейдет следующему демону. Типичная многозадачность без лишних костылей.

Более того, благодаря такой схеме большинство демонов могут быть запущены только тогда, когда в них возникнет реальная необходимость. Так, например, CUPS вовсе не обязательно запускать во время инициализации ОС, когда нагрузка на систему и без того высока. Логичнее стартануть его, когда на печать будет отправлен первый документ. Systemd позволяет сделать такое, следя за активностью вокруг сокетов, и применяет похожий подход для монтирования файловых систем, подключая их к точкам монтирования только при попытке получить доступ к файлам (также демоны могут быть запущены при появлении в системе определенного файла-устройства).

Справедливости ради стоит сказать, что столь гениальное решение проблемы зависимостей было придумано и реализовано в Mac OS X с самого начала ее существования, но до автора systemd почему-то никто не обращал на это внимания.

Кстати, у самого systemd есть другая и явно уникальная для Linux характеристика: он умеет группировать процессы с помощью cgroups с установкой различных лимитов среды исполнения на всю группу (ограничения ресурсов, рабочий и корневой каталоги, umask, настройки OOM killer, параметр nice, приоритет операций ввода-вывода, приоритеты использования процессора и многое другое). То есть демонов теперь можно помещать в виртуальные окружения без использования какого бы то ни было дополнительного ПО, просто прописав в файл настроек systemd несколько строк.

Systemd уже доступен для скачивания и возможно будет включен в один из будущих релизов Fedora в качестве альтернативной системы инициализации. Инструкции по установке в другие дистрибутивы можно найти на официальной страничке: freedesktop.org/wiki/Software/systemd .

Установить Systemd в Ubuntu можно, выполнив следующие команды:

$ sudo add-apt-repository ppa:andrew-edmunds/ppa
$ sudo apt-get update
$ sudo apt-get install systemd

Далее следует отредактировать /boot/grub/grub.cfg, добавив к параметрам ядра строчку init=/sbin/systemd. После перезагрузки дистрибутив будет работать с новой системой инициализации, в чем можно убедиться с помощью команды:

$ sudo systemctl units-list

Для проверки состояния, запуска, остановки и включения служб используются аргументы status, start, stop и enable.

Ulatencyd: мгновенная реакция

Какой, на твой взгляд, самый важный параметр десктопной операционной системы? Хороший графический интерфейс? Количество доступных приложений? Простота использования?

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

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

Для разработчиков операционных систем это прописная истина, поэтому во все времена они стремились сделать свои ОС более интерактивными. У одних это получалось хорошо (привет BeOS), у других плохо (куда же без MS), но были и такие, у кого это не получалось вообще. Долгое время разработчики Linux совершенно не интересовались темой отзывчивости Linux на десктопах. Кон Коливас множество раз указывал им на проблемы, говорил о неповоротливости и медлительности Linux, писал патчи, ночами кодил новые планировщики задач, добивался их включения в ядро. Все напрасно, раз за разом патчи отвергали, а самого автора грубо отстраняли от дел.

Однако со временем труды Кона Коливаса окупились. Инго Молнар начитался его исходников и написал планировщик CFS (Completely Fair Scheduler), а Линукс незамедлительно включил его в ядро 2.6.23. После этого положение дел на десктопах существенно улучшилось, и Linux стал намного быстрее (при этом реализация Кона все равно продолжала показывать более впечатляющие результаты).

Второй важной вехой на пути Linux к десктопу стало включение знаменитого 200-страничного патча в ядро 2.6.38, а также появление его аналога на языке bash. Так Linux научился отделять интерактивные процессы от всех остальных демонов, серверов и bash-скриптов и наделять их более высокими приоритетами. Это событие еще больше улучшило ситуацию и сделало ее практически идеальной: теперь Linux не тормозил даже тогда, когда в фоне шла пересборка ядра в несколько потоков.
Наконец, третьим важным шагом для десктопного Linux (здесь я подхожу к самому главному) стало появление демона ulatencyd, способного регулировать отзывчивость системы динамически, подстраивая ее под изменяющиеся обстоятельства.

Как и ядерный патч, ulatencyd использует механизм cgroups для группировки интерактивных процессов и изменения их приоритетов, но на этом его работа не заканчивается. Демон использует эвристические алгоритмы для выявления «наиболее интерактивных» процессов, а также явных вредителей системы, таких как форк-бомбы и программы с большими утечками памяти. При этом первые получают еще больший приоритет, а вторые жестко урезаются в возможностях (получая низкий приоритет, ограничения на доступную память), изолируются или уничтожаются. Но что самое главное, в любой момент демон можно обучить новым правилам отбора процессов, так что мы теперь можем назначать самые высокие (даже реалтаймовые) приоритеты любимым играм, видеоплеерам и браузерам.

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

Чтобы установить ulatencyd, необходимо скачать его исходники со страницы и собрать с помощью стандартных cmake и make:

$ cmake
$ make
$ sudo make install

$ sudo /usr/local/sbin/ulatencyd -v 2

И понаблюдать за тем, как он группирует процессы по приоритетам:

$ ps xaf -eo pid,session,args,cgroup

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

relayd: по трем фронтам

Какая связь между мониторингом сетевых хостов, балансировкой нагрузки и прокси-сервером? Все это функции одной машины? Да, вполне возможно. Но что если я скажу, что все эти три функции тесно связаны между собой и должны быть реализованы в рамках одного универсального приложения? Бред? Никак нет.

Возьмем, к примеру, достаточно распространенную в узких кругах функцию сервера под названием «распределение нагрузки между несколькими DNS-серверами». Что нужно для ее решения? Во-первых, умение перенаправлять DNS-трафик на другой хост (от балансировщика к одному из реальных DNS-серверов).

Это можно сделать с помощью брандмауэра или особым образом настроенного BIND (несколько тяжеловесный вариант). Вовторых, умение выбирать наиболее подходящего кандидата для обработки запроса из списка DNS-серверов. Это уже сложнее, и здесь может понадобиться специализированное ПО или опять же брандмауэр (но очень хороший). В-третьих, умение проверять DNS-сервера на доступность и удалять упавших из списка. Нужен скрипт, пингующий хосты и управляющий списками, либо особые возможности брандмауэра (а такой есть?). В общем, долгое нудное велосипедостроение или покупка специализированного решения для конкретной задачи по нереальным ценам. А что если завтра вдруг понадобится сделать нечто подобное для SMTP?

Все править или вновь открывать кошелек? Не стоит, содержимое кошелька все-таки лучше приберечь, а костыли с велосипедами оставить спортсменам. Демон relayd, появившийся в OpenBSD 4.3, позволяет решить эту и еще огромное количество других, подобных и не очень, задач всего за несколько минут.

Он включает в себя возможности балансировщика нагрузки для протоколов уровней 3, 4 и 7, прокси уровня 7 (релей) и сервиса проверки доступности сетевых узлов (из которого и вырос).

На основе relayd можно строить самые разные конфигурации, начиная от простых прокси-серверов или SSL-акселераторов и заканчивая сложными решениями вроде прозрачных web-прокси с фильтрацией запросов и распределением нагрузки между несколькими web-серверами. И все это с помощью простого конфигурационного файла, длина которого даже в самых сложных конфигурациях редко превышает 50 строк.

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

# vi /etc/relayd.conf

Переменные и макросы

Адрес и порт нашего релея

relayd_addr="127.0.0.1"
relayd_port="8053"

Адреса трех DNS-серверов, которые будут обрабатывать

запросы

table { 192.168.1.1, 192.168.1.2, 192.168.1.3 }

Общие настройки

Интервал между проверками хостов на доступность

(10 секунд)

Таймаут для проверки хостов на доступность методом TCP

(если хост не отвечает дольше 200 мс - он в дауне)

Разделяем сервер на 5 процессов для более эффективной

обработки запросов

Логировать результаты проверки хостов на доступность

Настройки DNS-протокола

Параметры оптимизации соединения

dns protocol "dnsfi lter" { tcp { nodelay, sack, socket buffer 1024, backlog 1000 } }

Настройки релея

relay dnsproxy {

Прослушиваемый адрес и порт

listen on $relayd_addr port $relayd_port

Работаем с описанным ранее протоколом

protocol "dnsfi lter"

Оправляем DNS-пакеты одному из перечисленных в таблице

DNS-серверов, предварительно проверив его на доступность

forward to port 53
mode loadbalance check tcp
}

Наиболее важные части этого конфига находятся в теле директив dns protocol и relay. Первая представляет собой нечто вроде шаблона, который используется для того, чтобы не повторять одни и те же настройки протоколов в других частях конфигурационного файла (relayd поддерживает три протокола: HTTP, DNS и TCP). Вторая - это настройка релея, в котором указаны прослушиваемый порт, проксируемый протокол, его настройки и информация о том, каким образом и какому хосту должны быть перенаправлены пакеты. В нашем случае прокси должен отправить DNS-запрос одному из трех серверов с предварительной проверкой на доступность (здесь используется проверка методом TCP-рукопожатия, но relayd поддерживает множество других методов, начиная от ping и заканчивая попыткой установить SSLсоединение). При этом, если один из DNS-серверов окажется в дауне, relayd автоматически исключит его из списка до тех пор, пока плановая проверка на доступность (интервал между проверками указан в опции interval) не покажет его работоспособность.

Для тестирования конфигурации можно использовать следующую форму запуска relayd:

# relayd -d -vv -f /etc/relayd.conf

Так демон не уйдет в фон и будет вести подробную распечатку всех своих действий. После отладки конфигурации можно настроить запуск демона во время загрузки системы. Для этого достаточно поместить строку relayd_flags=»» в файл /etc/rc.conf.local.

FreeBSD fscd: красота минимализма

Этого раздела не должно было быть в статье. Демон fscd настолько простой инструмент, что писать о нем отдельно мне казалось излишним. С другой стороны, не писать о нем нельзя, потому как это один из ярчайших примеров правильного решения задачи в стиле UNIX. А задача у разработчиков FreeBSD была следующая.
Различные системные и не очень демоны могут время от времени падать (или начинать вести себя как идиоты, что еще хуже). На домашней машине это не страшно, упавшего можно перезапустить руками или отправить комп в перезагрузку. Но что делать на сервере, где админ бывает редко?

Сервисы надо мониторить и перезапускать по мере необходимости. Как это сделать? Естественно, встроить эту функциональность в систему инициализации (ведь именно она занимается запуском демонов). И, например, в Solaris так и сделано, да настолько экстравагантно, что сам Линус Торвальдс ногу сломит, пока разберется с его настройкой. Разработчики FreeBSD поступили проще. Они написали отдельный демон, который способен работать со скриптами инициализации FreeBSD, оставаясь совершенно независимой системой. Вся соль в том, что fscd получился настолько простым, что им можно пользоваться, не читая man-страниц и не беспокоясь о том, что он может упасть. Посуди сам, чтобы заставить fscd следить за, например, sshd, нужно ввести всего одну команду:

# fscadm enable sshd /var/run/sshd.pid

Все, fscd запомнит этот выбор и автоматически включит мониторинг после перезагрузки машины. Единственное условие: у подконтрольного демона должен быть инициализационный файл в каталоге /etc/rc.d (или /usr/local/etc/rc.d) и запись в файле /etc/rc.conf, включающая его (это очевидно).

Демон fscd будет доступен только во FreeBSD 9.0, но его вполне можно скачать с официальной странички (people.freebsd.org/~trhodes/fsc) и собрать для восьмерки.

Выводы

Каждый день в мире UNIX появляется что-то новое, но очень редко это новое оказывается чем-то стоящим нашего внимания. В этой статье я рассказал о четырех системных компонентах UNIX, которые не только заслуживают особого внимания, но и несут реальную пользу. Кто знает, возможно в будущем они будут такой же неотъемлемой частью UNIX, как команда grep или демон syslog.

Info

В долгосрочной перспективе автор собирается превратить systemd в полноценный менеджер сессий, способный заменить gnomesession и kdeinit.
Кроме всего прочего, systemd обладает функциями монитора для демонов, так что возможности fscd встроены в него от рождения.
Отказ от использования скриптов - один из методов ускорить процесс загрузки. Многие задачи инициализации systemd способен произвести через прямой вызов нужных команд, без использования скриптов.
Прежнее название relayd - hostated (от слов host state, «состояние хоста»), было изменено на теперешнее в связи с расширением функционала.

Я хотел бы поговорить о новой системе инициализации systemd, чья поступь неумолимо захватывает популярные linux дистрибутивы. Данное наступление многих людей пугает и не спроста последнее время большинство срача в Интернете про линукс системы сводится к теме: быть или не быть с systemd?

Позвольте мне начать издалека. Будучи молодым, осваивал свою первую операционную систему из мира open source — FreeBSD. Как новичок я не понимал как правильно делать свои стартовые скрипты для не системного софта. С системным софтом во FreeBSD относительно просто. Вам нужен ssh? Укажите sshd_enable=»YES» в /etc/rc.conf и вам будет дано. А как запускать свои программные поделки при старте системы? Мой молодой ум в те времена не нашёл ничего лучше как создавать исполняемый стартовый скрипт в /usr/local/etc/rc.d/ типа так

Если скрипт имеет бит исполняемости и обрабатывает параметры start и stop, то в принципе это работало. Если правильно писать скрипты, используя rc.subr, то можно даже указать какие службы должны быть уже быть запущенными до вашего старта. Самое главное что нужно понять — вам придётся писать shell код для старта вашей программы . Это ни хорошо, ни плохо. Это факт и всё.

После первого знакомства с Linux я реально был напуган её системой инициализации, безгранично царствущей в те времена. 7 уровней ада инициализации от 0 до 6, где 4 уровень не используется. Стартовые скрипты лежат в одном месте, а с помощью симлинков с хитрыми именами в другом месте вы пытаетесь объяснить системе что и когда вы хотите запустить. Имя симлинка несёт не смысловую нагрузку, а функциональную! Имя симлинка начинается с К (для примера K60crond) и это указание убить службу. Имя c буквы S (для примера S40crond) — запустить службу. Числа, следующие перед именем службы задают порядок запуска скриптов. Вы мало того, что опять пишете код запуска и остановки сервиса, но и ещё кувыркаетесь с именами симлинков. Только не говорите мне про утилиты, которые облегчают этот мартышкин труд. Они не облегчают, а скрывают эстетическое несовершенство.

А теперь systemd. Вы не пишите простыни какого-либо кода. Вы не колдуете с именем файла или с именами симлинков на него. Вы просто указываете что запустить и всё.

Со временем ваш стартовый unit изменится и количество строк в нём увеличится. Но это будут строки, которые объясняют системе инициализации systemd ЧТО нужно сделать, а НЕ КАК это делать. Сразу скажу, я не спец по systemd. Он относительно недавно вошёл в нашу жизнь и моё знакомство по серьёзному началось после переключения с upstart на systemd моей рабочей Убунту 15.04. Но не являясь спецом, хотелось бы рассказать о своих мыслях по поводу систем инициализации.

Вот внедрил я с коллегами систему виртуализации на базе ProxmoxVE и программным хранилищем Ceph. Перевели мы свои физические сервера в новый виртуальный мир. Появилась возможность легко сделать виртуальные сервера другим отделам на моём предприятии под их задачи и проекты. И вот первый такой виртуальный сервер поставил жизненный вопрос. Помня прошлый зоопарк из разных версий FreeBSD и дистрибутивов Linux, от которого я избавился, переведя все системы на Ubuntu Server LTS, я оставил за собой все root права внутри гостевой операционной системы. С помощью механизма sudo разрешаю нужные привилегии человеку, который будет курировать уже работу сервисов внутри гостевой ОС. И вот человек ваяет в папке скрипт на Python 3, который сам себе веб-сервер и сам себе аля Zabbix каких-то локальных ресурсов. Человек не задумывается, что в идеале для его самописного скрипта нужно организовать автостарт на сервере. Пара моих обновлений сервера и его перезагрузка наглядно это показали.

Как мне быть как админу? Не являясь автором скрипта и не желая вмешиваться в его судьбу, в системе Init мне необходимо создать свой скрипт-обёртку на sh, в котором я запускаю и останавливаю сторонний для меня питоновский скрипт. Потом должен буду сделать нужные симлинки. Если завтра этот человек скажет мне, что его скрипт дорос до хранения данных мониторинга в базе данных MySQL, то мне нужно организовать загрузку питоновского скрипта-демона ПОСЛЕ сервиса MySQL. В systemd нужно добавить строку After в свой файл unit и указать требуемое, а вот в Init я сомневаюсь что отделался бы одной строкой изменений.

Я благодарен systemd уже за то, что он избавляет меня от программирования в вопросах автостарта. Как админу мне нравится systemd тем, что он единственный на сегодняшний день кто поможет вам со сложными демонами. Если в простом случае демон функционирует как один процесс, всё действительно очень просто. Для остановки демона в своём скрипте вы будете писать что-то типа kill $(cat /var/run/daemon.pid). А если демон работает в сложном сценарии, порождая из разрешённых вами программ другие процессы? Когда вы убиваете основной процесс, он может остановить все свои дочерние процессы, а может и не остановить. Systemd с помощью cgroup единственная сейчас система инициализации, способная остановить демона вне зависимости от того, сколько раз он форкался, и как бы он ни пытался сбежать из-под вашего контроля при помощи двойного форка или форк-бомбардировки. После неудачного stop сложного демона, вы скорее всего сделаете ему kill и потом будете искать в выводе ps зомби-процессы, пытаясь их завершить. Скорее всего всё закончится перезагрузкой всего сервера. А systemctl kill работает чисто и железно.

Кратко хочется подытожить моё мнение о systemd. Спасибо ему за лёгкость и простоту "вмешательства" в операционную систему , абсолютный контроль за демонами . А в будущем, подходя к своим и не своим серверам, спасибо за одноообразие в лице одной системы инициализации — systemd.

Изучаем и используем Systemd

Оригинал: Understanding and Using Systemd
Автор: Carla Schroder
Дата публикации: 18 September 2014
Перевод: Н.Ромоданов
Дата перевода: декабрь 2014 г.

Нравится нам или нет, но появился systemd, так что нам следует знать, что с ним делать.

Ценность systemd является спорной по нескольким причинам: он заменяет то, что, как думают многие пользователи Linux, заменять не требуется, и все гримасы разработчиков systemd не завоевывают сердца и умы. Скорее наоборот, о чем свидетельствует знаменитый блог LKML, в котором Линус Торвальдс отстранил разработчика systemd Кая Зиверса (Kay Sievers) от разработок ядра Linux.

Интересно, когда личности позволяют вставать на пути. Как ни интересно разглагольствовать и отпускать красочные эпитеты, но это к делу не относится. Ибо в течение многих лет системе Linux было достаточно SysVInit и BSD init. Потом появились добавления к менеджерам сервисов, например, такие команды, как service и chkconfig, которые должны были сделать управление сервисами проще, но для меня это было лишь то, что просто нужно было выучить, что не сделало задачи проще, а лишь внесло больше беспорядку.

Затем появились Upstart и systemd со всеми дополнительными примочками для обеспечения совместимости с SysVInit.

Все это замечательно, но надо было умудриться в этом всем этом разобраться. Теперь Upstart вышел в отставку в пользу systemd, и в Ubuntu вы найдете массу библиотек и инструментов для работы с systemd. Просто для интереса посмотрите в Ubuntu список файлов в пакете systemd-services:

$ dpkg -L systemd-services

Для того, чтобы узнать, для чего все это нужно, загляните на страницы man.

Всегда страшно, когда разработчики начинают возиться вокруг ключевых подсистем Linux, поскольку мы просто можем утонуть в том, что нам предлагают. Если нам не нравится конкретная программа, среда рабочего стола или команда и есть несколько альтернатив, то легко воспользоваться чем-то другим. Но основные подсистемы сидят глубоко в ядре, во всевозможных скриптах управления, а также в зависимостях, поэтому их замена — задача нетривиальная.

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

Первые шаги с systemd

Фирма Red Hat является изобретателем и вдохновителем внедрения механизма systemd, поэтому лучшие дистрибутивы для использования этого средства, это — Red Hat Enterprise Linux, клоны RHEL, например, CentOS и Scientific Linux, и, конечно, хорошо известная Fedora Linux, которая всегда поставляется с самыми последними, самыми большими и кровоточащими новинками.

Мои примеры из системы CentOS 7.

Опытные пользователи RH могут в RH 7 по-прежнему пользоваться командами service и chkconfig, но давно уже пора отказаться от них в пользу нативных команд systemd. systemd развивается и команды service и chkconfig не поддерживают нативные сервисы systemd.

Нет нашего любимого файла. Вместо этого, у нас есть каталог /, заполненный символическими ссылками на файлы в каталоге. Скрипты инициализации находятся в каталоге; для того, чтобы при загрузке системы запустить сервис, его нужно связать с. Когда вы включаете новый сервис, то это для нас делает команда systemctl, как, например, в следующем примере для ClamAV:

# systemctl enable [email protected] ln -s ‘/usr/lib/systemd/system/[email protected]’ ‘/etc/systemd/system/multi-user.target.wants/[email protected]’

Как вы узнаете имя скрипта инициализации и откуда его взять? В Centos7 они добавлены в отдельные пакеты. Многие серверы (например, Apache) нельзя запустить с помощью systemd и для них нет скриптов инициализации systemd. Для ClamAV предлагаются скрипты инициализации как для systemd, как и для SysVInit, поэтому вы можете установить этот пакет любым способом, который вы предпочитаете:

$ yum search clamav clamav-server-sysvinit.noarch clamav-server-systemd.noarch

Так что же внутри этих скриптов инициализации? Мы это можем это увидеть сами:

$ less /usr/lib/systemd/system/[email protected] .include /lib/systemd/system/[email protected] Description = Generic clamav scanner daemon WantedBy = multi-user.target

Теперь вы можете видеть, как systemctl узнает, где установить символическую ссылку, и в этом скрипте инициализации также указана зависимость от другого сервиса — [email protected].

Команда systemctl отображает состояние всех установленных сервисов, у которых есть скрипты инициализации:

$ systemctl list-unit-files —type=service UNIT FILE STATE […] chronyd.service enabled [email protected] static [email protected] disabled

Для сервиса есть три возможных состояния: включено (enabled), отключено (disabled) и статическое состояние (static). Состояние включено означает, что в каталоге.want есть символическая ссылка. Состояние отключено означает, это не так. Статическое состояние означает, что сервис отсутствует в секции его скрипта инициализации, поэтому вы не можете ни включить, ни выключить его. Статические сервисы обычно зависят от других сервисов и управление ими осуществляется автоматически. Это можно видеть на примере ClamAV, т. к. сервис [email protected] зависит от сервиса [email protected] и работает только тогда, когда работает сервис [email protected].

Ни одно из этих состояние не указывает на то, запущен ли сервис. Об этом можно узнать с помощью команды ps, либо для того, чтобы получить более подробную информацию, воспользуйтесь командой systemctl:

$ systemctl status bluetooth.service bluetooth.service — Bluetooth service Loaded: loaded (/usr/lib.systemd/system/bluetooth.service; enabled) Active: active (running) since Thu 2014-09-14 6:40:11 PDT Main PID: 4964 (bluetoothd) CGroup: /system.slice/bluetooth.service |_4964 /usr/bin/bluetoothd -n

Если вы знаете, как спросить, то команда systemctl расскажет вам все, что вы хотите узнать.

Список команд

Вероятно, что вы будете пользоваться лишь следующими командами:

# systemctl start # systemctl stop # systemctl restart # systemctl reload $ systemctl status # systemctl is-active $ systemctl list-units —type service —all

в systemd есть 12 типов юнитов. .service представляют собой системные сервисы, и, когда вы запускаете любую из вышеперечисленных команд, вы можете не указывать расширение.service, поскольку systemd предполагает, что это сервис, если вы не укажете что-нибудь другое. Другие типы юнитов:

Target: группа юнитов
Automount: точка автомонтирования файловой системы
Device: имена устройств ядра, которые вы видите в sysfs и в udev
Mount: точка монтирования файловой системы
Path: файл или каталог
Scope: внешние процессы, не запускаемые с помощью systemd
Slice: юнит управления процессами
Snapshot: состояние, сохраненное с помощью systemd
Socket: сокет IPC (межпроцессного взаимодействия)
Swap: файл подкачки
Timer: таймер systemd.
Изучаем и используем Systemd

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

$ systemctl list-units —type [имя юнита]

Так в чем выигрыш?

По какой-то причине, кажется, что сторонники замены SysVInit одержимы попыткой уменьшить время загрузки. Мои системы с system, такие как CentOS 7, загружаются не намного быстрее, чем прочие. В любом случае, это не то, что меня особенно беспокоит, поскольку в большинстве случаев скорость загрузки измеряется только до появления приглашения для входа в систему, а не тем, как долго система будет запускаться и когда ей можно будет полностью пользоваться. В этом отношении система Microsoft Windows уже давно стала нечестным чемпионом, поскольку приглашение для входа в систему появляется достаточно быстро, а затем требуется еще несколько минут для того, чтобы загрузить и запустить все прочее, что в значительной степени вам не нужно. Как мне кажется, что когда появляется еще один глупый экран с предложением обновления Oracle Java, мне начинает казаться, что это насилие над мною.

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

$ systemd-analyze blame 5.728s firewalld.service 5.111s plymouth-quit-wait.service 4.046s tuned.service 3.550s accounts.daemon.service […]

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

Если вам понравилась статья, поделитесь ею с друзьями:

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

Замечание. Все ниже перечисленные команды надо выполнять из под пользователя root.

Для смены пользователя или получения прав root используйте команды «su -» или «sudo».

1. Команда shutdown, с ключом -r.

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

# shutdown -r now

При использование команды shutdown можно задать перезагрузку в конкретное время с выводом информирующих сообщений.

# shutdown -r 10:30 «REBOOT SYSTEM»

2. Команда reboot.

Команда reboot выпоняет все необходимые операции для остановки системы, эта команда может быть вызвана командой shutdown -r, но может использоваться отдельно. Данная команда записывает в журнал логов время остановки системы, уничтожает незавершенные процессы, выполняет системный вызов sync, ждет завершения записи на диск, а только после этого прекращает работу ядра и перезагружает систему Linux.

# reboot

3. Команда telinit 7.

С помощю этой команды можно задать демону init перейти на определенный уровень выполнения, а именно цифра 7 говорит о том что нужно прейти на 7-ой уровеь (перезагрузка). Команда telinit не поддерживает задание паузы и вывода предупреждающих сообщений. Обычно используется при проверке изменений внесеных в файл inittab.

# telinit 7

Выключение Linux системы.

1. Команда shutdown, с ключом -h.

# shutdown -h now

2.
Мне нравится systemd.

Команда halt.

Команда идентична команде reboot по своим действиям, разница в том, что команда halt выключает систему.

# halt

3. Используем команду poweroff.

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

# poweroff

4. Команда telinit 0

Идентична команде telinit 7 только переходит на уровень 0, что означает остановку системы.

# telinit 0

Вот и все, рассмотрение основных способов выключение и перезагрузки Linux систем из командной строки завершено.

Как включить программу в автозагрузку или, наоборот, удалить из автозагрузки в CentOS ?
Посмотреть список автозагрузки можно при помощи команды:

# /sbin/chkconfig —list

atop 0:off 1:off 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off httpd 0:off 1:off 2:off 3:on 4:off 5:off 6:off ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Отображаются 7 уровней выполнения, которые обозначаются числами от 0 до 6.
Уровень 0 - остановка системы (halt) - работа системы должна быть прекращена;
Уровень 1 - однопользовательский режим работы - система инициализирует минимум служб и даёт единственному пользователю (как правило, суперпользователю) без проведения аутентификации командную строку.

Изучаем и используем Systemd

Как правило, этот режим используется для восстановления системы;
Уровень 2 - многопользовательский режим - пользователи могут работать на разных терминалах, вход в систему с процессом аутентификации;
Уровень 3 - многопользовательский сетевой режим - в отличие от предыдущего уровня, осуществляется настройка сети и запускаются различные сетевые службы;
Уровень 4 - не имеет стандартного толкования и практически не используется;
Уровень 5 - запуск графической подсистемы - по сравнению с уровнем 3 производится также старт графической подсистемы X11, и вход в систему осуществляется уже в графическом режиме;
Уровень 6 - перезагрузка системы - при включении этого режима останавливаются все запущенные программы и производится перезагрузка.

В основном, используются уровни 2, 3, 5.

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

# chkconfig -add nginx

которая автоматически активирует 2, 3, 4, 5 уровни. Также можно указать необходимые уровни:

# chkconfig —level 345 nginx on

Как удалить программу из автозагрузки?

# chkconfig —del nginx

Как добавить службу в автозагрузку?

Запущенные процессы в Linux

Дата:2012-10-26

Как узнать список запущенных процессов в Linux?

Процесс — это программа выполняющаяся в системе.

1) В большинстве случаев для исследования процессов в Linux используется команда «ps», которая может выполняться как в текстовом режиме так и иметь графическую оболочку.

#ps ax — отображает полную информацию о процессах

PID TTY STAT TIME COMMAND
1 ? Ss 0:03 /sbin/init

По хорошему эта команда, наверное, нам нужна для отслеживания процессов и убития зависших, как по нажатию сочетания клавиш ctrl+alt+delete мы попадаем в диспетчер задав в Виндовсе и можем остановить зависший процесс.

Ее можно применить вместе с grep, для более быстрого поиска нужного нам процесса
# ps ax | grep pptp
2036 pts/0 S+ 0:00 grep pptp
17676 ? Ss 0:00 /usr/sbin/pptpd
Здесь он нам нашел наш поиск и сам процесс под номером 17676

А можем воспользоваться уже готовой утилитой поиска процесса
# pgrep -l pp
2111 pptpd

2) Убить процесс нам поможет команда:
# kill 17676 — которая принудительно прекратит его выполнение
# killall pptpd — останавливает процесс по имени

3) Если вам нужно древовидное отображение процессов, то на помощь придет утилита:
# pstree
init —acpid
—apache2—5*
—atd
—cron
—dd
—freshclam
—6*
—klogd
—miniserv.pl
—named—3*[{named}]
—nmbd
—pptpd
—slapd—2*[{slapd}]
—smbd—smbd
—sshd—sshd—bash—pstree
—syslogd
—udevd
—xinetd

Здесь, соответственно, видна зависимость процессов друг от друга в древовидном виде.
А более подробную зависимость можно посмотреть если добавить ключ -a
# pstree -a
4) Еще одна очень полезная утилита.
# top — отображение процессов в реальном времени

Tasks: 52 total, 1 running, 51 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.7%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 247780k total, 242104k used, 5676k free, 64152k buffers
Swap: 465844k total, 184k used, 465660k free, 127556k cached
PID USER PR NI VIRT SHR S %CPU RES %MEM TIME+ COMMAND
2094 root 18 0 2304 852 R 0.3 1064 0.4 0:01.05 top
5549 syslog 15 0 1932 528 S 0.3 680 0.3 49:43.08 syslogd
5571 root 15 0 1868 440 S 0.3 532 0.2 72:10.96 dd
1 root 15 0 2840 540 S 0.0 1684 0.7 0:03.12 init
2 root 12 -5 0 0 S 0.0 0 0.0 0:00.00 kthreadd
Здесь отображается используемая память и процессор, приостановленные и рабочие процессы.

Отсюда можно произвести изменение приоритета процесса или удалить его. Просмотреть состояние процесса (простой, остановленный, зависший и др.)

# gtop — может применяться в графическом режиме.

Другие команды Linux

Так, что бы стало понятно зачем и как можно применять команды в Linux. продемонстирую небольшой скрипт Bash.
Данный скрипт проверяет имеется ли процесс c именем smb и в том случае если его нет происходит его старт.
grep -v grep необходим, что бы исключить сам процесс поиска smb

#!/bin/bash
ps ax | grep -v grep | grep smb
if [ $? -ne 0 ]
then
/etc/init.d/smb start
else
echo «демон работает» > /dev/null
fi

Plutonit.ru — Администрирование, настройка Linux и Windows 2009 — 2018

Понадобилось на днях написать простой bash-скрипт, для постоянного мониторинга каталога на наличие в нем файлов *.pdf, с последующей их конвертацией в формат txt. Скрипт должен был работать в фоновом режиме и автоматически запускаться при перезагрузке.

Для реализации работы в фоне сначала написал Linux - демон на C, но потом решил что для моей задачи это слишком, и реализовал это при помощи Systemd.

Для начала нужно убедиться, что ваш дистрибутив работает с Systemd, командой:

readlink /proc/1/exe
если вывод будет /sbin/init - то у вас используется SysV, и вам нужно либо обновить дистрибутив, как в моем случае, я обновил Debian 7 Wheezy до Debian 8 Jessie, либо реализовать работу в фоновом режиме другим способом.

Если вывод такой:
/lib/systemd/systemd - то все в порядке, у вас Systemd.

Systemd осуществляет свою работу с помощью так называемых юнитов systemd.
Юнит (Unit) - это конфигурационный файл, расположенный в одной из директорий:

/run/systemd/system/ - юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
/etc/systemd/system/ - юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме. В этом каталоге мы и будем создавать свой юнит.

Переходим в каталог /etc/systemd/system/ и создаем в нем, либо копируем какой-либо существующий файл, к примеру sshd.service, и в нем пишем:

[ Unit]

Description =MyBashScript

After =syslog.target

[ Service]
ExecStart =/ bin/ bash "/home/user/scripts/script.sh"
Type =forking
[ Install]
WantedBy =multi-user.target
Alias =bash.service

Подробнее о каждой секции:
Секция :
Содержит общую информацию о сервисе, его описание, и то, что он должен стартовать после запущенного демона Syslog.

Секция
Непосредственная информация о нашем сервисе.
Параметр ExecStart указывает на исполняемый файл нашего сервиса. Нужно указывать абсолютные пути, в случае с bash-скриптом путь до скрипта берем в одинарные кавычки.
Type=forking означает, что запускаемый скрипт будет работать в режиме демона. Если мы хотим, чтобы скрипт выполнился один раз, то указываем Type=simple.

Секция
Последняя секция содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы хотим, что сервис должен быть запущен, когда будет активирована цель multi–user.target (это аналог init 3 в SysV).
Alias=bash.service - для удобства создадим алиас, чтобы проще управлять нашим сервисом через systemctl.

Это работающий файл сервиcа Systemd, с небольшим функционалом. Сохраняем файл, и выполняем команду systemctl daemon-reload , чтобы Systemd узнал о нашем сервисе, и вы могли его запустить командой systemctl start bash.service .
У меня запустить получилось не с первого раза, так как сначала я указал не абсолютный путь в параметре ExecStart секции . После исправления Systemd все равно ругался на ту же ошибку, помогла перезагрузка.

Для просмотра состояния, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl . В более ранних версиях Systemd использовались команды service и chkconfig, они по прежнему включены в систему, в основном для обратной совместимости.

Ниже представлены основные команды systemctl:

systemctl start name.service – запуск сервиса.
systemctl stop name.service - остановка сервиса
systemctl restart name.service - перезапуск сервиса
systemctl try-restart name.service - перезапуск сервиса только, если он запущен
systemctl reload name.service - перезагрузка конфигурации сервиса
systemctl status name.service - проверка, запущен ли сервис с детальным выводом состояния сервиса
systemctl is-active name.service - проверка, запущен ли сервис с простым ответом: active или inactive
systemctl list-units --type service --all – отображение статуса всех сервисов
systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
systemctl disable name.service – деактивирует сервис
systemctl reenable name.service – деактивирует сервис и сразу активирует его
systemctl is–enabled name.service – проверяет, активирован ли сервис
systemctl list-unit-files --type service – отображает все сервисы и проверяет, какие из них активированы
systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd

В операционной системе linux, так же как и в Windows, кроме обычных программ, которые могут взаимодействовать с пользователем есть еще один вид программ. Это работающие в фоне службы. Важность служб тяжело переоценить, они следят за состоянием системы, обеспечивают автоматическое подключение внешних устройств и сети, позволяют процессам взаимодействовать с оборудованием (dbus), а также в виде служб реализованы различные веб-серверы и серверы баз данных. В отличие от пользовательских программ, службы выполняются в фоне, и пользователь не имеет к ним прямого доступа. Пользователь еще не вошел в систему, только началась загрузка а основные службы уже запущенны и работают.

В этой статье мы рассмотрим управление службами Linux. Мы не будем трогать уже устаревшие системы, такие как SysVinit, сосредоточимся только на Systemd. Вы узнаете, как посмотреть запущенные службы linux, а также останавливать и запускать их самому.

Чтобы всем этим управлять нужна основная служба - система инициализации, которая будет запускать службы linux в нужный момент, следить чтобы они нормально работали, записывать сообщения логов, и самое главное позволять останавливать службы. Раньше, для управления службами использовались скрипты. Я уже говорил, что можно запустить службу из терминала, так вот, каждая служба запускалась в фоновом режиме одна за другой, без возможности параллельного запуска и возвращала свой PID процесса скрипту инициализации, он сохранялся и потом с помощью этого PID можно было проверить работает ли служба и остановить службу linux если это нужно. Все это можно сделать и вручную.

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

Служба в Systemd описывается файлом юнита, в нем описано что с ней нужно делать и как себя вести. Существуют такие типы служб:

service - обычная служба, программа
target - группа служб
automount - точка автоматического монтирования
device - файл устройства, генерируется на этапе загрузки
mount - точка монтирования
path - файл или папка
scope - процесс
slice - группа системных служб systemd
snapshot - сохраненное состояние запущенных служб
socket - сокет для взаимодействия между процессами.

Нас будут интересовать только service, и совсем немного target, но мы рассмотрели все остальные, чтобы вы смогли взглянуть на картину немного шире. Основы рассмотрели, теперь будет настройка служб LInux.

Утилита systemctl

В Systemd есть специальный инструмент для управления службами в Linux - systemctl. Эта утилита позволяет делать очень много вещей, начиная от перезапуска службы linux и проверки ее состояния, до анализа эффективности загрузки службы. Синтаксис у утилиты такой:

$ systemctl опции команда служба служба...

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

Рассмотрим все по порядку. Опции очень сильно зависят от команд, поэтому рассмотрим их позже, а пока пройдемся по командах:

list-units - посмотреть все службы (юниты), аналог опции -t
list-sockets - посмотреть все службы сокетов
start - запустить службу linux
stop - остановить службу linux
reload - обновить конфигурацию службы из файла юнита
restart - перезапустить службу
try-restart - перезапустить службу, только если она запущена
reload-or-restart - обновить конфигурацию затем выполнить перезапуск службы linux, если не поддерживается - только перезапустить
isolate - запустить только одну службу вместе с ее зависимостями, все остальные остановить
kill - отправить сигнал завершения процессу используется вместе с опциями --signal и --kill-who
is-active - проверить запущена ли служба linux
is-failed - проверить не завершилась ли служба с ошибкой
status - посмотреть состояние и вывод службы
show - посмотреть параметры управления службой в Linux
reset-failed - перезапустить службы linux, завершившиеся с ошибкой
list-dependencies - посмотреть зависимости службы linux
list-unit-files - вывести все установленные файлы служб
enable - добавить службу в автозагрузку
disable - удалить службу из автозагрузки
is-enabled - проверить если ли уже служба в автозагрузке
reenable - сначала выполнить disable потом enable для службы
list-jobs - все запущенные службы linux независимо от типа
snapsot - сохранить состояние служб, чтобы потом восстановить
daemon-reload - обновить конфигурацию всех служб
mask - сделать юнит недоступным
unmask - вернуть файл службы linux

А теперь основные опции:

-t, --type - тип служб для вывода
-a, --all - показать все известные службы, даже не запущенные
-q - минимальный вывод
--version - версия программы
--no-pager - не использовать постраничную навигацию
--no-legend - не выводить подробное описание
-f - принудительное выполнение команды
--runtime - не сохранять вносимые изменения после перезагрузки
-n - количество строк вывода лога для команды status
--plain - использовать обычный текстовый режим вместо деревьев
--kill-who - задать процесс, которому нужно отправить сигнал
--signal - сигнал, который нужно отправить.
--state - отфильтровать список служб по состоянию.

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

Управление службами Linux

Теперь, когда вы уже знаете все основы, команды и параметры можно переходить к делу. Со всеми остальными тонкостями разберемся по пути. Сначала давайте посмотрим запущенные службы linux. Нас будут интересовать только программы, а не все эти дополнительные компоненты, поэтому воспользуемся опцией type:

systemctl list-units --type service

Команда отобразила все службы, которые известны systemd, они сейчас запущены или были запущены. Программа не пересматривает все файлы, поэтому будут показаны только те службы, к которым уже обращались. Состояние loaded - означает, что конфигурационный файл был успешно загружен, следующая колонка active - служба была запущена, а running или exited значит выполняется ли сейчас служба или она успешно завершила свою работу. Листать список можно кнопками вверх/вниз.

Следующая команда позволяет получить список служб linux, в который входят все службы, даже не запущенные, те, которые не запускались, но известны systemd, но это еще не все службы в системе:

systemctl list-units --type service -all

systemctl list-units --type service --state running

Или те, которые завершились с ошибкой:

systemctl list-units --type service --state failed

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

systemctl list-unit-files

Теперь отфильтруем только службы linux:

systemctl list-unit-files --type service

Здесь вы тоже можете использовать фильтры по состоянию. Теперь вы знаете как посмотреть запущенные службы linux, идем дальше.

Чтобы запустить службу используется команда start, например:

sudo systemctl start application.service

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

Остановить службу linux можно командой:

sudo systemctl stop application

Посмотреть состояние службы позволяет команда status:

sudo systemctl status application

Здесь вы можете видеть, состояние running, exited, dead, failed и т д. А также несколько последних строчек вывода программы, которые очень помогут решить проблему с запуском если она возникнет.

Как вы знаете, systemd позволяет автоматически загружать службы при запуске системы по мере их надобности. Команда list-unit-files показывает добавлена ли служба в автозагрузку.

Вообще, здесь может быть несколько состояний - enabled - в автозагрузке, disabled - автозагрузка отключена, masked - служба скрыта и static - значит что служба в автозагрузке, но вы не можете ее отключить.

Поэтому чтобы получить список служб linux, запускаемых автоматически достаточно отфильтровать ее вывод по состоянию:

systemctl list-unit-files --state enabled