Вокруг systemd уже несколько лет ходят «холивары». Systemd пришел к нам на замену System V Init в Linux. Есть как сторонники systemd, так и его противники. Давайте рассмотрим, чем же так плох systemd:

1. Systemd нарушает философию Unix «Делать одну вещь и при этом хорошо», представляя просто сложный набор малосвязных бинарников. Его зона ответственности давно уже выросла за рамки системы инициализации и начинает распространяться на управление питанием, устройствами, точками монтирования, cron-ом, шифровнием диска, API сокетов, журналами (syslog), конфигурацией сети, управлением сессиям, предчтение(readahead), определение разделов, регистрация контейнеров [виртуализация], управление именем хоста-временем-локалью, mDNS/DNS-SD, консоли Linux и прочие штуки - все в одном. На повестке дня - дальнейшее расширение systemd и его внедрение в среду GNU/Linux было выяснено во время «2014 GNOME Asia talk». Дайте нам KISS.

2. Журналы systemd (для journald) сохраняются в очень сложном бинарном формате и могут быть запрошены только journalctl. Это делает журналы потенциально повреждаемыми и они не имеют ACID-совместимых транзакций. Вы бы не хотели, чтобы с системными журналами что-то произошло. Совет от systemd разрабов? Забейте. Единственный путь создать традиционные логи - это запустить syslogd как rsyslog вместе с journald. Так же там есть встроенный HTTP сервер. QR коды тоже можно отдавать через него, с помощью libqrencode.

3. Так как systemd очень завязан на API ядра Linux, разные версии systemd несовместимы с разными ядрами и портируемость бессмысленно снижена в разных компонентах. Это политика изолирования , которая, конечно же, вгоняет экосистему Linux в свою собственную клетку, работая как препятствие в разработке портируемого ПО как с Linux, так и Unix-деривативами. Так же это пораждает трудности с бекпортированием изменений в системой длительной поддержки.

4. udev и dbus становятся обязательными зависимостями. По факту, udev был влит в ветку systemd очень давно. Интеграция менеджера «device node»(который был частью Linux ядра) - это нелегкое решение. Здесь высокая политическая подоплека (имеется в виду политика разработчиков) и много пакетов, зависящих от udev, стали зависимы от systemd, несмотря на форки вроде eudev. Начиная с systemd-209 разработчики ввели собственный нестандартный и малодокументированный sd-bus API, который замещает некоторые задачи libdbus. Далее они решили перенести udev на этот новый транспорт, заменили Netlink и сделали udev наглухо привязанным к systemd демоном. Эффект, конечно, значителен.

5. systemd представляет хелпер который снимает coredump-ы (дампы ядра) и перенаправляет их либо в /var/lib/systemd/coredump либо в journal, где они должны быть запрошены через coredumpctl. Последнее, причем - было поведением по умолчанию и его похоже вернут. Это означает, что пользователей и админов держат за идиотов, но более важно, в основе своей склонная к повреждениям природа логов journald превращает это в серьезную помеху и безответственный выбор при дизайне системы. Также это может создать усложнения в многопользовательских средах в плане привелегий.

6. Размер systemd (видимо, в файлах и мегабайтах - прим.пер.) превращает его в большую «единственную точку отказа». На момент написания systemd имел 9 отчетов CVE (уязвимости) с начала внедрения в марте 2010. Вроде и не много, но его всепроникающая (в плане ответственности за компоненты) и важная суть может стать лакомым кусочком для взломщиков, так как его широта поменьше чем ядро, но настолько же критично по последствиям (прим. пер. - по мне так это уже лицемерие и лукавство.)

7. systemd имеет вирусный характер, его расширения добавляют новые API, но продолжая зависеть именно от его инициализации. Его охват функциональности и расползание как зависимость по куче пакетов означает, что мейнтейнеры дистрибутивов будут обязаны вынуждать переход или сносить напрочь (старое). Например, GNOME обычно использует компоненты systemd вроде logind и поддержка не-systemd систем становится сложной. Под Wayland GNOME использует logind который снова заставляет использовать systemd. Все больше мейнтейнеров прописывают в зависимости systemd по этой причине. Быстрый рост в принятии в такие дистрибутивы, как Debian, Arch Linux, Ubuntu, Fedora, openSUSE показывает, что многие пытаются запрыгнуть в уходящий поезд, иногда бездумно (может тут не точно перевел). Например, странно, что от него зависят Weston compositor, Polkit, upower, udisks2, PackageKit, и тп. Так же ничего особо не дает то, что systemd не хочет запускаться под пользователем.

8. systemd запускает (clusters - теснится, толпится - прим. пер.) себя под PID 1, вместо того чтоб работать как отдельный гипервизор процессов. Так как он контролирует кучу компонентов, существует тьма вариантов, в которых он может помереть (закрашиться) и отправить в небытие всю систему (см. выше про точку отказа). Мы так же отмечаем, что чтобы снизить надобности перезагрузки, systemd предоставляет механизм для перезапуска systemctl в реальном времени. Но если с ним чего не так, то система опять идет крахом. Так же есть разные пути, как это может произойти, включая невозможность прочитать предыдущее несовместимое состояние. Это, похоже, другой пример SPOF (одна точка отказа) и ненужном бремени в и так уже критичном комноненте (init).

9. systemd разработан с glibc-в-уме и не особо поддерживает другие libc-ы. В общем, идея разрабов systemd в стандартной libc библиотеке - та, что баг-в-баг повторит glibc.

10. Сложная «душевная» организация systemd (метафора пер.) делает очень сложной расширение за пределами его собственных рамок (среды) разработки. В то время, как запустить шел скрипт из файлов модулей как-то можно, весьма сложно написать реализацию поведения, которая идет из коробки, с учетом всех этих крутых фич. Много пользователей чаще хотят написать сложные программы, которые прямо взаимодействуют с API systemd, или даже модифицировать (его исходники). Кто-то может побеспокоиться о большом количестве путей в коде в критичной для системы программе, включая возможность того что systemd не синхронизируется с шиной сообщений при загрузке и зависнет. Это противоположно традиционному иниту, который определяем и предсказуем по архитектуре.

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

12. systemd вообще похоже не знает что за хренью он хочет быть. Он иногда описан как «system daemon» или как «базовый блок в пространстве пользователя чтобы сделать ОС», оба термина слишком неоднозначны. Он поглощает функциональность которая пренадлежала util-linux, беспроводным инструментам (wireless tools), syslog и прочим проектам. У него нет четкого направления, кроме как причуды самих же разработчиков. Что забавно, несмотря на цели по стандартизации дистрибутивов Linux, у него нет четкого стандарта и он по сути просто катится, как перекати-поле.

Большинство дистрибутивов Linux в качестве менеджера системы и сервисов используют systemd.

systemctl является основной командой для управления сервисами в systemd.

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

Также я приведу описание наиболее важных опций используемых в service-файлах с примерами реальных service-файлов.

Создание Сервиса в Systemd

Создайте service-файл /etc/systemd/system/foo-daemon.service (замените foo-daemon на имя вашего сервиса):

$ sudo touch /etc/systemd/system/foo-daemon.service $ sudo chmod 664 /etc/systemd/system/foo-daemon.service

Откройте файл foo-daemon.service и пропишите минимальные настройки, которые позволят управлять сервисом с помощью systemctl:

Description=Foo ExecStart=/usr/sbin/foo-daemon WantedBy=multi-user.target

Путь К Демону: Если вы не знаете путь к демону, попробуйте which foo-daemon .

После создания нового service-файла необходимо перезапустить systemd:

$ sudo systemctl daemon-reload

Теперь вы можете делать start , stop , restart и проверять status сервиса:

$ sudo systemctl start foo-daemon $ sudo systemctl stop foo-daemon $ sudo systemctl restart foo-daemon $ systemctl status foo-daemon

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

$ sudo systemctl enable foo-daemon

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

$ journalctl -u foo-daemon

Опции Service-файла в Systemd

Service-файла в systemd обычно состоит из трех секций.

Общие элементы конфигурации сервиса настраиваются в секциях и

Параметры конфигурации конкретного сервиса настраиваются в секции .

Важные Опции Секции

Опция	Описание
Description	Краткое описание юнита.
Documentation	Список ссылок на документацию.
Before , After	Порядок запуска юнитов.
Requires	Если этот сервис активируется, перечисленные здесь юниты тоже будут активированы. Если один из перечисленных юнитов останавливается или падает, этот сервис тоже будет остановлен.
Wants	Устанавливает более слабые зависимости, чем Requires . Если один из перечисленных юнитов не может успешно запуститься, это не повлияет на запуск данного сервиса. Это рекомендуемый способ установления зависимостей.
Conflicts	Если установлено что данный сервис конфликтует с другим юнитом, то запуск последнего остановит этот сервис и наоборот.

Список всех опций секции :

$ man systemd.unit

Важные Опции Секции

Список всех опций секции :

$ man systemd.unit

Важные Опции Секции

Опция	Описание
Type	Настраивает тип запуска процесса. Один из: simple (по умолчанию) — запускает сервис мгновенно. Предполагается, что основной процесс сервиса задан в ExecStart . forking — считает сервис запущенным после того, как родительский процесс создает процесс-потомка, а сам завершится. oneshot — аналогичен типу simple , но предполагается, что процесс должен завершиться до того, как systemd начнет отслеживать состояния юнитов (удобно для скриптов, которые выполняют разовую работу и завершаются). Возможно вы также захотите использовать RemainAfterExit=yes , чтобы systemd продолжал считать сервис активным и после завершения процесса. dbus — аналогичен типу simple , но считает сервис запущенным после того, как основной процесс получает имя на шине D-Bus. notify — аналогичен типу simple , но считает сервис запущенным после того, как он отправляет systemd специальный сигнал. idle — аналогичен типу simple , но фактический запуск исполняемого файла сервиса откладывается, пока не будут выполнены все задачи.
ExecStart	Команды вместе с аргументами, которые будут выполнены при старте сервиса. Опция Type=oneshot позволяет указывать несколько команд, которые будут выполняться последовательно. Опции ExecStartPre и ExecStartPost могут задавать дополнительные команды, которые будут выполнены до или после ExecStart .
ExecStop	Команды, которые будут выполнены для остановки сервиса запущенного с помощью ExecStart .
ExecReload	Команды, которые будут выполнены чтобы сообщить сервису о необходимости перечитать конфигурационные файлы.
Restart	Если эта опция активирована, сервис будет перезапущен если процесс прекращен или достигнут timeout, за исключением случая нормальной остановки сервиса с помощью команды systemctl stop
RemainAfterExit	Если установлена в значение True , сервис будет считаться запущенным даже если сам процесс завершен. Полезен с Type=oneshot . Значение по умолчанию False .

Список всех опций секции :

$ man systemd.service

Примеры Service-файлов в Systemd

Description=The NGINX HTTP and reverse proxy server After=syslog.target network.target remote-fs.target nss-lookup.target Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t ExecStart=/usr/sbin/nginx ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=true WantedBy=multi-user.target Description=The Apache HTTP Server After=network.target remote-fs.target nss-lookup.target Type=notify EnvironmentFile=/etc/sysconfig/httpd ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful ExecStop=/bin/kill -WINCH ${MAINPID} KillSignal=SIGCONT PrivateTmp=true WantedBy=multi-user.target Description=Redis persistent key-value database After=network.target ExecStart=/usr/bin/redis-server /etc/redis.conf --daemonize no ExecStop=/usr/bin/redis-shutdown User=redis Group=redis WantedBy=multi-user.target

Я хотел бы поговорить о новой системе инициализации 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

Системные демоны - одна из ключевых подсистем 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.

Links

• дом systemd под крылом: freedesktop.org/wiki/Software/systemd ; freedesktop.org
• исходные тексты systemd: cgit.freedesktop.org/systemd ;
• код ulatencyd: github.com/poelzi/ulatencyd ;
• исходники fscd: people.freebsd.org/~trhodes/fsc .

Info

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

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

Теперь разработчики многих дистрибутивов встраивают systemd по умолчанию, а пользователи возмущаются навязыванием чего-то конкретного и ограничением свободы выбора. С systemd правда что-то не так, или все это лишь пустая болтовня?

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

У вас назреет вопрос: почему вопрос выбора системы инициализации, важной составляющей ОС, может вызывать спор? Как минимум потому, что есть свобода выбора. Таких вопросов не возникает у пользователей macOS и Windows просто по причине невозможности выбора. Но на GNU/Linux системах выбор всегда есть. Еще одна проблема в том, что разные системы инициализации работают по-своему. Стиль SysVinit существовал еще со времен SystemV, которая была разработана еще в 1983 году. Это установило стандарт инициализации POSIX систем.

Стиль инициализации SysV не менялся де-факто в течение почти трех десятилетий. Многие IT-специалисты и разработчики программного обеспечения не хотят отказываться от SysVinit, поскольку он стабильно работал на протяжении многих лет, и был достаточно прост в понимании. Таким образом, попытка внедрить что-то новое вместо SysV была встречена резким негативом.

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

Нововведения

Уже более 10 лет назад поднялся вопрос: systemd или upstart? В попытке внести больше возможностей в процесс инициализации, Canonical выпустила Ubuntu 6.10 в 2006 году с Upstart. Upstart был нацелен на обратную совместимость с самого начала его существования. Он запускает все службы без лишних манипуляций. По этой причине многие дистрибутивы перешли на Upstart. Сделали это, конечно, не все.

В 2010 году, инженеры из Red Hat Леннарт Поттеринг и Ки Сиверс стали разрабатывать systemd. Fedora 15 поставлялась уже с ней, что делало ее самым первым дистрибутивом работающим с systemd. За последующие три года много дистрибутивов перешли на нее по двум большим причинам. Как минимум из-за новизны новой системы инициализации, а также потому, что не хотели оставаться позади. Но, если разработчики сделали свой выбор в пользу systemd, почему возникает так много споров? Откуда было столько неприязни к тому, к чему в итоге пришли практически единогласно? Ответ: выбор.

Systemd

Systemd предлагает множество улучшений по сравнению с SysV и Upstart, а также предоставляет другие компоненты, которые разработчики могут использовать для более тесной интеграции системы. Разработчики пишут ПО, которое зависит от systemd и (или) любой из его многочисленных других демонов, таких как journald, udevd, logind или networkd. Из-за такого подхода страдают дистрибутивы, не использующие systemd. Кроме того, пока количество демонов, предоставляемых проектом systemd продолжает расти, systemd становится все более зависимым от них же.

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

Заключение

Неужели systemd настолько плох? Конечно нет. Данная система имеет открытый исходный код, а у людей в любом случае есть выбор. Это не вина systemd что основные дистрибутивы перешли на сторону прогресса. Как уже упоминалось, непринятие нового имеет место быть, но существуют множество альтернатив. Никто не препятствует пользоваться Sysvinit, Upstart, или другими системами инициализации вроде OpenRC, Sinit, runit (при поддержке оных конкретным дистрибутивом). Существуют много дистрибутивов, которые не используют systemd, взять те же Gentoo, Slackware, Dragora и PCLinuxOS, и многие операционные системы UNIX, такие как FreeBSD, OpenBSD и DragonFlyBSD. Главная мысль - выбор есть всегда. Это неотъемлемая часть Open Source сообщества.

Выводы

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

На завершение, видео о том, как происходит загрузка в Systemd: