В операционной системе 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

Все службы, запускаемые по умолчанию. Можете также посмотреть службы static. Чтобы добавить службу в автозагрузку linux используйте команду enable:

sudo systemctl enable application

А для того чтобы убрать ее из автозагрузки.

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

Как и ранее, чтобы запустить какой-то скрипт при загрузке системы, вы можете поместить его в файл /etc/rc.d/rc.local . Однако стоит учесть специфику запуска этого скрипта в systemd.

service-файл отвечающего за него юнита выглядит следующим образом:

$ cat /lib/systemd/system/rc-local.service Description=/etc/rc.d/rc.local Compatibility After=network.target Type=forking ExecStart=/etc/rc.d/rc.local start TimeoutSec=0 RemainAfterExit=yes SysVStartPriority=99

Отсюда видно, во-первых, что файл /etc/rc.d/rc.local обязан быть исполняемым.

А во-вторых, видно, что сервис rc-local имеет зависимость только от цели network.target . Параметр SysVStartPriority=99 отвечает только за приоритет по сравнению с другими sysVinit-скриптами, которых в Fedora становится все меньше. С учетом параллельной загрузки это означает, что скрипт, который вы разместите в файле rc.local может быть запущен слишком рано , например, до старта нужных сервисов. Поэтому, если вы разместите в этом файле скрипты перезапуска апача, то, с большой вероятностью, они не сработают.

В версиях до Fedora 17, не было зависимости от network.target , так что, там этот скрипт запускался практически в самом начале.

С помощью systemd-юнита

Более естественный для systemd способ запускать скрипты - это создание своего собственного юнита.

Просто создайте файл /etc/systemd/system/my_stuff.service со следующим текстом:

Description=Run my stuff Requires=network.target After=network.target Type=oneshot RemainAfterExit=True ExecStart=/some/script --with-some-parameters ExecStart=/some/other/script WantedBy=multi-user.target

Здесь Requires - указывает цель, после которой необходимо запустить сервис, After означает, что сеть должна быть полностью запущена к моменту старта, WantedBy - цель, для которой запускается сервис. В ExecStart должен быть указан полный путь к скрипту или исполняемому файлу, поскольку переменная PATH не используется.

multi-user.target - это аналог init 3 в sysVinit. Подробнее о реализации runlevel-ов в systemd, можно прочесть по ссылке .

В такой конфигурации скрипты будут запускаться сразу после запуска сети и старта всех интерфейсов. Однако systemd позволяет гораздо более гибкую настройку. Например, для выполнения скриптов после запуска графического DM можно использовать After: systemd-user-sessions.service

Небольшой пример: После появления облачного хранилища Яндекс.Диск, захотелось автоматически монтировать его в файловую систему через davfs2 (с заранее положенными логином и паролем в /etc/davfs2/secrets). Прописывание в fstab не дало результатов, как и прописывание в rc.local, поскольку в Fedora 16 оба они обрабатывались ещё до поднятия сети. А вот создание модуля по вышеприведённому образцу решило проблему.

Дополнительно

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

Systemctl status rc-local.service

или загляните в файл /var/log/boot.log (он появится если в параметрах загрузки убрать quiet , см.

Большинство дистрибутивов 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

При работе в операционной системе нужно постоянно запускать разные программы. Следить за их состоянием. Перезапускать упавшее. Существует целый пласт утилит, который решает эту задачу (от простейшего init.d до навороченного svc). Сейчас в Linux стандартом де-факто стал systemd – его используют все современные дистрибутивы. Это – очень короткое и очень простое введение в systemd. Минимум текста – максимум пользы.

SystemD – это менеджер загрузки. Он получает управление от ядра при старте операционной системы (init), запускает разные сервисы и следит за их состоянием (например – перезапускает упавшие). Идеолог – Леннар Поттеринг из RedHat. Systemd очень своеобразная штука, умеет она довольно много и устройство у нее довольно сложное. Systemd заслуженно любят за мощный и гибкий функционал – это здорово облегчает жизнь разработчика и админа. Systemd заслуженно ненавидят за тягу к изобретению уже реализованных в операционной системе вещей и спорное поведение в некоторых вопросах безопасности.

Эта статья – краткое практическое руководство. Теории тут – минимум. Если вас интересует устройство systemd – вам в официальное руководство .

Введение и терминология

Systemd отвечает за запуск программ и сервисов после старта операционной системы. Он следит за процессом загрузки, решает что запустить и как. Строго говоря, он делает ровно то же самое, что делал SystemV init. Systemd писали значительно позже init – в нем пытались починить вещи, которые в init сделаны плохо. Например, в init нет возможности сделать зависимость запуска одного сервиса от другого. Так же init не поддерживает параллельной загрузки. Параллельная загрузка сервисов радикально ускоряет старт операционной системы.

Unit

Unit – это описание сервиса (в широком смысле этого слова). Unit-файл описывает все настройки сервиса, как его запускать, когда (очередность, зависимости) и что делать, если запуск не удался. Unit-ы, которые пишет пользователь руками – должны находится в /etc/systemd/system и иметь окончание.service в названии. Юниты, которые устанавливают пакеты – находятся в ином месте. Если в нескольких папках лежит юнит с одним и тем же именем – применяется тот, что лежит в /etc/systemd/system . Пример юнита:

Description=etcd – highly-available key value store Documentation=https://github.com/coreos/etcd Documentation=man:etcd After=network.target Wants=network-online.target Environment=DAEMON_ARGS= Environment=ETCD_NAME=%H EnvironmentFile=-/etc/default/%p WorkingDir=/var/lib/etcd Type=notify User=etcd PermissionsStartOnly=true ExecStart=/usr/bin/etcd $DAEMON_ARGS Restart=on-abnormal RestartSec=10s LimitNOFILE=65536 WantedBy=multi-user.target

Я специально взял юнит посложнее, чтобы пример был наглядным. На что обратить внимание:

  • Description – человеко-читаемое описание. Показывается по команде service status
  • After – начать загрузку после того, как начнется загрузка сервиса (или цели)
  • Wants – опциональная зависимость. Подробнее ниже, в разделе про зависимости
  • Environment – создать переменную окружения при запуске этого сервиса
  • WorkingDir – демон запускается из этой папки. Аналогично cd /var/lib/etcd перед запуском
  • Type – тип сервиса. Подробнее ниже
  • User – имя пользователя, от которого будет запущен сервис
  • PermissionsStartOnly – используется, если перед стартом нужна какая-то специальная подготовка – создание папок, изменение прав и так далее. При PermissionsStartOnly=true эти действия будут выполнятся от root. Без – от имени User
  • ExecStart – что, собственно, запускать. Обязательно полный путь
  • RestartOn – при каких условиях перезапускать
  • WantedBy – в какой target должен быть установлен сервис. Подробнее – в разделе про target-ы

Виды Unit-ов

Systemd может обслуживать процессы с разным поведением. Тип описывает, как systemd будет с ним взаимодействовать. Есть следующие варианты:

  • Type=Simple – самый стандартный тип. Процесс остается в foreground, stdout перехватывается systemd. Это тип по умолчанию.
  • Type=Forking – прямая противоположность. Процесс должен форкнуться и отсоединится от foreground. Для этого типа юнитов должен быть указан pid через директиву PIDFile .
  • Type=oneshot – процесс, который успешно выполняется (не делая fork) и завершается. Пример – монтирование файловых систем. Рекомендуется добавить RemainAfterExit=yes в юнит, чтобы результаты работы процесса остался в статусе юнита.
  • Type=notify – аналог simple, но в этом случае сам процесс сообщит systemd о том, что он закончил загрузку и готов к работе.

Взаимодействие с unit-ами

После каждого изменения файла юнита (создание/изменение/удаление) – нужно перечитывать изменения, так как состояния юнитов systemd кеширует:

systemctl daemon-reload

Запус, состояние, остановка:

#запуск systemctl start service start #состояние systemctl status service status #остановка systemctl stop service stop #сервис в автозагрузку systemctl enable #полностью запретить запуск сервиса (даже команда service start не поможет) systemctl mask #разрешить запуск обратно systemctl unmask

Systemd имеет свою собственную реализацию логирования (хотя по умолчанию в syslog копию сообщения он тоже отправляет). Чтение сообщений от сервисов – командой journalctl. Команда очень мощная, умеет много. Ниже примеры

#чтение информации по юниту journalctl -u #чтение по PID journalctl _PID=12 #аналогично по конкретному файлу journalctl /usr/bin/atd #чтение информаций о юнитах, завершившихся с ошибкой journalctl -xn #чтение журнала с момента загрузки journalctl -b #чтение журнала с определенного момента journalctl --since="2018-01-24 10:15:10" journalctl --since "10 minutes ago" #постоянное отслеживание событий (аналог tail -f) journalctl -f #по умолчанию systemd обрезает строки по длине экрана. Запретим ему это: journalctl -l #фильтры можно комбинировать journalctl -u redis -f -l --since "10 minutes ago"

Управление зависимостями, очередность загрузки юнитов

Для управления зависимостями в unit есть ключевые слова Wants , Requires и After:

  • After – сервис начнет загрузку после того, как начнет загружаться сервис, указанный в After .
  • Wants – сервис начнет загрузку после того, как закончит загружаться сервис, указанный в Wants . Статус загрузки этого сервиса не важен – даже если он упал и загрузится не смог – юнит попытается стартовать. То есть зависимость эта опциональная, и нужна она только для того, чтобы наш сервис начал загружаться не раньше, чем другой – закончит.
  • Requires – сервис начнет загрузку после того, как сервис, указанный в Requires закончит загрузку успешно . Если сервис-зависимость загрузится не смог – наш сервис так же упадет с ошибкой (точнее – он даже не будет стартовать).

Targets

Target – целевое состояние системы. Именно Target определяет, какие сервисы будут загружены и в каком порядке. Аналог из мира sysV init – runlevel. Основные виды таргетов:

  • poweroff – отключение системы
  • rescue – режим восстановления, однопользовательский (init 1)
  • multi-user – сетевой режим без графической оболочки, (init 3)
  • graphical – сетевой режим с графической оболочкой (init 5)
  • emergency – аварийная командная строка, минимальный функционал

Цели могут наследоваться друг от друга. Например, graphical включает в себя загрузку всего, что есть multiuser + после этого – подгрузку графической оболочки.

Взаимодействие с целями:

#список целей systemctl list-units --type=target #перейти в нужную цель (например – загрузится из сетевого режима в графический) systemctl isolate graphical.target #выбрать target по умолчанию systemctl set-default multi-user.target

Заключение

systemd на данный момент - стандарт в linux-based операционных системах. Инструмент мощный, удобный и популярный, пусть и не без особенностей. Надеюсь, эта статья поможет начать им пользоваться.