Systemd linux что это
Обновлено: 06.07.2024
systemd — это система инициализации и системный диспетчер, который стал новым стандартом для дистрибутивов Linux. Из-за сложной адаптивности знакомство с системой systemd оправдано, поскольку это существенно упростит администрирование серверов. Изучение и использование инструментов и демонов, которые включают systemd , поможет вам лучше оценить предоставляемые возможности и гибкость или, по крайней мере, работать с минимальным количеством проблем.
В этом руководстве мы обсудим команду systemctl , которая является инструментом центрального управления для контроля системы инициализации. Мы расскажем о том, как управлять службами, проверять статус, изменять состояние системы и работать с файлами конфигурации.
Обратите внимание, что хотя система systemd стала системой инициализации по умолчанию для многих дистрибутивов Linux, она не используется повсеместно во всех дистрибутивах. По мере изучения этого руководства, если ваш терминал выводит ошибку bash: systemctl is not installed , скорее всего, на вашей машине установлена другая система инициализации.
Управление службами
Основополагающая цель системы инициализации заключается в инициализации компонентов, которые должны запускаться после загрузки ядра Linux (традиционно называются компоненты пользовательского пространства). Система инициализации также используется для управления службами и демонами для сервера и в любой момент времени работы системы. С учетом этого мы начнем с нескольких базовых операций по управлению службами.
В systemd целью большинства действий являются «модули», являющиеся ресурсами, которыми systemd знает, как управлять. Модули распределяются по категориям по типу ресурса, который они представляют, и определяются файлами, известными как файлы модулей. Тип каждого модуля можно вывести из суффикса в конце файла.
Для задач по управлению службами целевым модулем будут модули службы, которые имеют файлы модулей с суффиксом .service . Однако для большинства команд по управлению службами вы можете не использовать суффикс .service , поскольку systemd достаточно умна, чтобы знать, что вы, возможно, хотите работать со службой при использовании команд по управлению службами.
Запуск и остановка служб
Чтобы запустить службу systemd , используя инструкции в файле модуля службы, используйте команду start . Если вы работаете как пользователь без прав root, вам потребуется использовать sudo , поскольку это влияет на состояние операционной системы:
Как мы уже упомянули выше, systemd будет искать файлы *.service для команд управления службами, так что команду можно легко ввести следующим образом:
Хотя вы можете использовать вышеуказанный формат для общего администрирования, для ясности мы будем использовать суффикс .service для остальных команд, чтобы предельно четко выражать цель, над которой мы работаем.
Чтобы остановить работающую в данный момент службу, можно использовать команду stop :
Перезапуск и перезагрузка
Чтобы перезапустить работающую службу, можно использовать команду restart :
Если данное приложение может перезагрузить файлы конфигурации (без перезапуска), вы можете выдать команду reload для инициализации этого процесса:
Если вы не уверены, есть ли у службы функция перезагрузки своей конфигурации, можно использовать команду reload-or-restart . Это перезагрузит необходимую конфигурацию при наличии. В противном случае будет перезагружена служба для выбора новой конфигурации:
Включение и отключение служб
Указанные выше команды полезны для запуска или остановки служб во время текущего сеанса. Чтобы дать команду systemd автоматически запускать службы при загрузке, их необходимо включить.
Для запуска службы во время загрузки используйте команду enable :
При этом будет создана символическая ссылка из системной копии служебного файла (обычно в /lib/systemd/system или /etc/systemd/system ) в месте на диске, где systemd ищет файлы для автозапуска (обычно /etc/systemd/system/ some_target .target.wants ; что такое цель, мы рассмотрим далее в этом руководстве).
Чтобы отключить автоматический запуск службы, можно ввести следующее:
При этом будет удалена символическая ссылка, что укажет на то, что служба не должна запускаться автоматически.
Помните, что включение службы не запустит ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, необходимо дать обе команды, start и enable .
Проверка статуса служб
Чтобы проверить статус службы в вашей системе, можно использовать команду status :
При этом вы получите статус службы, иерархию контрольных групп и первые несколько строк журнала.
Например, при проверке статуса сервера Nginx вы можете видеть следующий вывод:
Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий.
Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду is-active :
Это вернет текущий статус модуля, который обычно active или inactive . Код выхода будет «0», если он активен, и результат будет проще парсить в скрипты оболочки.
Чтобы увидеть, включен ли модуль, можно использовать команду is-enabled :
Это выведет информацию о том, что служба enabled или disabled , и снова установит код выхода на «0» или «1» в зависимости от вопроса команды.
Третья проверка заключается в проверке того, находится ли модуль в состоянии сбоя. Это означает, что была проблема, которая запустила данный модуль:
Это вернет active , если он работает должным образом, или failed , если возникла ошибка. Если модуль был намеренно остановлен, может вернуться unknown или inactive . Статус выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на какой-либо другой статус.
Обзор состояния системы
Команды до сих пор были полезны для управления отдельными службами, но они не очень подходят для понимания текущего состояния системы. Существует ряд команд systemctl , предоставляющих эту информацию.
Список текущих модулей
Чтобы увидеть список всех активных модулей, о которых знает systemd , можно использовать команду list-units :
Это покажет вам список всех модулей, которые у systemd активны в системе. Результат будет выглядеть примерно так:
Вывод содержит следующие столбцы:
- UNIT: имя модуля systemd
- LOAD: указывает на то, парсила ли systemd конфигурацию модуля. Конфигурация загруженных модулей сохраняется в памяти.
- ACTIVE: краткое состояние активности модуля. Обычно это довольно стандартный способ сообщить, запущен модуль или нет.
- SUB: это состояние более низкого уровня, которое указывает более подробную информацию о модуле. Это часто зависит от типа модуля, состояния и фактического метода работы модуля.
- DESCRIPTION: краткое текстовое описание того, чем является модуль/что делает.
Поскольку команда list-units показывает по умолчанию только активные модули, для всех вводов выше отобразится loaded в столбце LOAD и active в столбце ACTIVE. Это отображение фактически является поведением по умолчанию systemctl при вызове без дополнительных команд, поэтому вы увидите то же, что и при вызове systemctl без аргументов:
Мы можем использовать systemctl для вывода различной информации путем добавления дополнительных флагов. Например, чтобы увидеть все модули, которые загрузила система systemd (или пыталась загрузить), независимо от их активности в данный момент, можно использовать следующий флаг --all :
Это отобразит все модули, которые загрузила или пыталась загрузить система systemd независимо от текущего состояния системы. Некоторые модули становятся неактивными после работы, а некоторые модули, которые система systemd пыталась загрузить, могут не быть найдены на диске.
Вы можете использовать другие флаги для фильтрации этих результатов. Например, мы можем использовать флаг --state= для указания состояния LOAD, ACTIVE или SUB, которое мы хотим увидеть. Вам потребуется сохранить флаг --all , чтобы systemctl позволила отображать неактивные модули:
Другим распространенным фильтром является фильтр - --type= . Мы можем задать systemctl только для отображения модулей интересующего нас типа. Например, чтобы увидеть только активные модули службы, мы можем:
Список все файлов модулей
Команда list-units отображает только модули, которые система systemd пыталась парсить или загрузить в память. Поскольку systemd будет считывать только те модули, которые считает необходимыми, это необязательно будут все модули, доступные в системе. Чтобы увидеть все доступные файлы модулей в путях systemd , включая те, что система systemd пыталась загрузить, можно использовать команду list-unit-files :
Модули являются представлениями ресурсов, о которых знает systemd . Поскольку система systemd необязательно считывала все определения модуля в этом виде, она представляет информацию только о самих файлах. Вывод содержит два столбца: файл модуля и состояние.
Состояние будет, как правило, enabled , disabled , static или masked . В этом контексте static обозначает, что файл модуля не содержит раздел install , который используется для включения модуля. Эти модули как таковые не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость другого модуля и не должен работать самостоятельно.
Мы рассмотрим сразу же, что означает masked .
Управление модулями
До сих пор мы работали со службами и отображали информацию о модулях и файлах модулей, о которых знает systemd . Однако мы можем узнать более конкретную информацию о модулях, используя некоторые дополнительные команды.
Отображение файла модуля
Чтобы отобразить файл модуля, который система systemd загрузила в систему, можно использовать команду cat (она была добавлена в версию systemd 209). Например, чтобы увидеть файл модуля демона-планировщика atd , можно ввести следующее:
Вывод — это файл модуля, известный выполняемому в настоящее время процессу systemd . Это может быть важно, если вы недавно модифицировали файлы модуля или если вы переопределяете определенные опции во фрагменте файла модуля (мы рассмотрим это позже).
Отображение зависимостей
Чтобы увидеть дерево зависимостей модуля, можно использовать команду list-dependencies :
При этом отобразится иерархическая схема зависимостей, с которой необходимо работать, чтобы запустить интересуемый модуль. Зависимости в этом контексте включают те модули, которые либо требуются, либо желательны для модулей выше.
Рекурсивные зависимости отображаются только для модулей .target , которые указывают состояние системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг --all .
Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флаг --reverse . Другие полезные флаги --before и --after могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно, перед ними и после.
Проверка свойств модуля
Чтобы увидеть свойства более низкого уровня модуля, можно использовать команду show . При этом будет выведен список свойств, заданных для указанного модуля с помощью формата key=value :
Если вы хотите отобразить одно свойство, можно передать флаг -p с именем свойства. Например, чтобы увидеть конфликты, которые есть у модуля sshd.service , можно ввести следующее:
Маскировка и снятие маскировки модулей
В разделе управления службами мы узнали, как остановить или отключить службу, но systemd также имеет возможность отметить модуль как полностью незапускаемый, автоматически или вручную, связав его с /dev/null . Это называется маскировкой модуля, и она возможна с помощью команды mask :
Это не позволит запустить службу Nginx автоматически или вручную, пока она замаскирована.
Если вы проверите list-unit-files , вы увидите, что служба теперь указана как замаскированная:
Чтобы снять маскировку модуля и сделать его доступным для использования снова, используйте команду unmask :
Это вернет модуль в его предыдущее состояние, что позволит его запускать или включать.
Редактирование файлов модулей
Хотя конкретный формат файлов модулей выходит за рамки этого руководства, systemctl предоставляет встроенные механизмы для редактирования и модификации файлов модулей при необходимости изменений. Эта функция добавлена в версию systemd 218.
Команда edit по умолчанию откроет фрагмент файла модуля для интересующего модуля:
Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение модуля. Каталог будет создан в каталоге /etc/systemd/system , который содержит название модуля с добавлением .d . Например, для nginx.service будет создан каталог под названием nginx.service.d .
В этом каталоге будет создан фрагмент под названием override.conf . При загрузке модуля systemd в памяти соединит фрагмент переопределения с полным файлом модуля. Директивы фрагмента получат приоритет над найденными в оригинальном файле модуля.
Если вы хотите редактировать весь файл модуля, а не создавать фрагмент, можно передать флаг --full :
Это загрузит текущий файл модуля в редактор, где его можно редактировать. После выхода из редактора измененный файл будет записан в /etc/systemd/system , что будет иметь приоритет над определением модуля системы (обычно находится где-то в /lib/systemd/system ).
Чтобы удалить какие-либо сделанные добавления, удалите либо каталог конфигурации модуля .d или модифицированный служебный файл из /etc/systemd/system . Например, для удаления фрагмента можно ввести следующее:
Чтобы удалить весь отредактированный файл модуля, добавим:
После удаления файла или каталога необходимо перезагрузить процесс systemd , чтобы он больше не пытался ссылаться на эти файлы и не возвращался к использованию системных копий. Для этого можно ввести следующую команду:
Настройка состояния системы (уровень запуска) с помощью целей
Целями являются специальные файлы модулей, которые описывают состояние системы или точку синхронизации. Как и другие модули, файлы, которые определяют цели, могут быть идентифицированы по суффиксу, которым в данном случае является .target . Цели сами по себе немного значат, а используются для группировки других модулей.
Их можно использовать, чтобы привести систему в определенные состояния, подобно тому, как другие системы инициализации используют уровни запуска. Они используются в качестве справки, когда доступны определенные функции, позволяя вам указывать желаемое состояние вместо необходимости использования отдельных модулей для получения этого состояния.
Например, swap.target используется для указания того, что переключение готово к использованию. Модули, являющиеся частью этого процесса, могут синхронизироваться с этой целью путем указания в своей конфигурации, что они WantedBy= или RequiredBy= swap.target . Модули, которым требуется возможность переключения, могут указывать это состояние с помощью спецификаций Wants= , Requires= и After= для указания характера их отношений.
Получение и настройка цели по умолчанию
Процесс systemd имеет цель по умолчанию, которую он использует при загрузке системы. Удовлетворение каскада зависимостей от этой одной цели приведет систему в желаемое состояние. Чтобы найти цель по умолчанию для вашей системы, введите:
Если вы хотите задать другую цель по умолчанию, можно использовать set-default . Например, если у вас установлен графический рабочий стол и вы хотите загрузить систему в него по умолчанию, можно изменить цель по умолчанию соответственно:
Список доступных целей
Вы можете получить список имеющихся целей в вашей системе, введя:
В отличие от уровней запуска, несколько целей могут быть активны одновременно. Активная цель указывает, что система systemd попыталась запустить все модули, привязанные к цели, и не попыталась закрыть их снова. Чтобы увидеть все активные цели, введите:
Изолирование целей
Можно запустить все модули, связанные с целью, и остановить все модули, не являющиеся частью дерева зависимостей. Команда, необходимая для этого, называется соответственно isolate . Она аналогична изменению уровня запуска в других системах инициализации.
Например, если вы работаете в графической среде с активным graphical.target , можно закрыть графическую систему и перевести систему в состояние многопользовательской командной строки путем изоляции multi-user.target . Поскольку graphical.target зависит от multi-user.target , а не наоборот, все графические модули будут остановлены.
Возможно, вы захотите посмотреть на зависимости цели, которую вы изолируете, перед выполнением этой процедуры, чтобы убедиться, что не остановлены важные службы:
Если вы удовлетворены модулями, которые будут сохранены в активном состоянии, можно изолировать цель, введя:
Использование комбинации быстрого ввода для важных событий
Для таких важных событий, как отключение или перезагрузка, определены цели. Однако для systemctl также есть несколько комбинаций быстрого ввода, обеспечивающих дополнительную функциональность.
Например, чтобы перевести систему в режим спасения (один пользователь), можно использовать команду rescue вместо isolate rescue.target :
Это обеспечит дополнительную функцию предупреждения всех подключенных пользователей о событии.
Чтобы остановить систему, можно использовать команду halt :
Для инициализации полного отключения можно использовать команду poweroff :
Перезапуск можно начать с помощью команды reboot :
Все это оповестит подключенных пользователей о том, что происходит событие, что-то, что только выполняет или изолирует цель, не сработает. Обратите внимание, что большинство машин будет привязывать более короткие, более традиционные команды для этих операций, чтобы правильно работать с systemd .
Например, для перезагрузки системы обычно можно ввести следующее:
Заключение
К этому моменту вы должны уже ознакомиться с некоторыми базовыми возможностями команды systemctl , которая позволяет взаимодействовать и контролировать экземпляр systemd . Утилита systemctl будет главной точкой взаимодействия для управления службами и состоянием системы.
Хотя systemctl работает главным образом с основным процессом systemd , в экосистеме systemd есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и сеансы пользователя, обрабатываются отдельными демонами и утилитами управления ( journald / journalctl и logind / loginctl соответственно). Знакомство с этими другими инструментами и демонами упростит задачу управления.
Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).
В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.
Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…
Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.
Systemd запускает сервисы описанные в его конфигурации.
Конфигурация состоит из множества файлов, которые по-модному называют юнитами.
Все эти юниты разложены в трех каталогах:
/usr/lib/systemd/system/ – юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее
/run/systemd/system/ — юниты, созданные в рантайме — тоже, наверное, нужная штука
/etc/systemd/system/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.
Юнит представляет из себя текстовый файл с форматом, похожим на файлы .ini Microsoft Windows.
[Название секции в квадратных скобках]
имя_переменной = значение
Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]
В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:
Далее следует блок переменных, которые влияют на порядок загрузки сервисов:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
Для запуска сервиса необходим запущенный сервис mysql:
Для запуска сервиса желателен запущенный сервис redis:
В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса
В секции Service указываем какими командами и под каким пользователем надо запускать сервис:
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Данный тип используется для запуска классических демонов.
Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:
Рабочий каталог, он делается текущим перед запуском стартап команд:
Пользователь и группа, под которым надо стартовать сервис:
Запрет на убийство сервиса вследствие нехватки памяти и срабатывания механизма OOM:
-1000 полный запрет (такой у sshd стоит), -100 понизим вероятность.
Команды на старт/стоп и релоад сервиса
ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon
ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop
ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart
Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.
Таймаут в секундах, сколько ждать system отработки старт/стоп команд.
Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла
В секции [Install] опишем, в каком уровне запуска должен стартовать сервис
multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»
Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service
Кладем этот файл в каталог /etc/systemd/system/
Смотрим его статус systemctl status myunit
Видим, что он disabled — разрешаем его
systemctl enable myunit
systemctl -l status myunit
Если нет никаких ошибок в юните — то вывод будет вот такой:
Запускаем сервис
systemctl start myunit
Смотрим красивый статус:
systemctl -l status myunit
Если есть ошибки — читаем вывод в статусе, исправляем, не забываем после исправлений в юните перегружать демон systemd
systemd позволяет пользователю управлять службами в личном, отдельном экземпляре systemd. Благодаря этому пользователь может запускать, останавливать, включать и отключать свои собственные юниты. Это очень удобно в случае демонов и служб, которые обычно запускаются для отдельного пользователя (mpd), или выполнения автоматизированных задач (например, скачивание почты).
Contents
Как это работает
Аналогично системным службам, пользовательские службы расположены в следующих каталогах (отсортированы по возрастанию приоритета):
-
/usr/lib/systemd/user/ где находятся службы, относящиеся к установленным пакетам.
- Имейте в виду, что systemd --user представляет собой процесс для каждого пользователя, а не для сессии. Смысл заключается в том, что большая часть ресурсов, обрабатываемых пользовательскими службами, такие как сокеты или файлы состояния будут создаваться отдельно для каждого пользователя (в его домашнем каталоге), и не за один сеанс. Это означает, что все пользовательские службы работают вне сеанса. Как следствие, программы, которые должны быть запущены внутри сессии, вероятно, прервут выполнение пользовательских служб. С помощью systemd в пользовательском сеансе обрабатывается довольно много данных. См [1] и [2] для получения подсказок о том, как идут дела.
- systemd --user выполняется как процесс, отдельный от родительского процесса systemd --system . Службы пользователей не могут ссылаться или зависеть от системных юнитов или юнитов других пользователей.
Основные настройки
Все пользовательские службы размещаются в
/.config/systemd/user/ . Если вы хотите запускать службы при первом входе в систему, выполните systemctl --user enable service для любой службы, которую вы хотите сделать автозагрузочной.
Совет: Если вы хотите включить службу для всех пользователей, а не для пользователя, выполняющего команду systemctl , запустите systemctl --user --global enable service от имени суперпользователя.Переменные окружения
Пользовательский процесс systemd не наследует какую-либо из переменных окружения, установленных в .bashrc или других. Существует несколько способов установить переменные окружения для systemd:
-
Для переменной $HOME пользовательского каталога, создайте файл .conf в каталоге
Смотрите environment.d(5) для получения дополнительной информации.
Одну переменную Вы можете установить в PATH .
После настройки можно использовать команду systemctl --user show-environment для проверки правильности значений.
Пример службы
Создайте drop-in каталог /etc/systemd/system/user@.service.d/ и внутри создайте файл с расширением .conf (например, local.conf ):
DISPLAY и XAUTHORITY
Переменная DISPLAY используется любым графическим приложением, чтобы знать, какой дисплей использовать, XAUTHORITY , чтобы указать путь к пользовательскому файлу .Xauthority , а также куки, необходимые для запуска Х-сервера. Если Вы планируете запускать графические приложения из процесса systemd, то эти переменные обязательно должны быть установлены. Systemd предоставляет скрипт в /etc/X11/xinit/xinitrc.d/50-systemd-user.sh для импорта этих переменных в пользовательскую сессию systemd на запуск X. [3] Так что если Вы не запускаете Х нестандартным образом, пользовательские службы должны знать переменные DISPLAY и XAUTHORITY .
Если изменить PATH и запланированный запуск приложений, которые используют службу systemd, Вы должны убедиться, что модифицированный PATH установлен и в среде systemd. Если предположить, что Вы установили переменную PATH в .bash_profile , то лучшим способом сделать systemd осведомленным о модификации PATH будет добавление в .bash_profile после PATH заданной переменной:
Обратите внимание, что это не повлияет на службы systemd, запущенные до импортирования PATH.
pam_environment
Автоматический запуск systemd от имени пользователя
Пользовательский процесс systemd запускается сразу после первого входа пользователя в систему, и будет убит после завершения последнего сеанса пользователя. Иногда может быть полезно запустить службу сразу после загрузки, и поддерживать процесс systemd запущенным даже после завершения последнего сеанса пользователя, например, чтобы некоторый пользовательский процесс работал без какой-либо открытой сессии. Для этой цели используются долговременные службы. Используйте следующую команду, чтобы включить долговременную службу для конкретного пользователя:
Важно: Служба systemd находится вне сессии, она запускается за пределами logind. Не используйте долговременные службы для включения автоматического входа в систему, иначе будет перерыв в работе сессии.Написание пользовательских юнитов
Пример
Ниже приведен пример варианта пользовательской службы mpd.
Пример с переменными
Ниже приведен пример пользовательской версии sickbeard.service , которая учитывает все переменные окружения пользовательских каталогов, где SickBeard может найти некоторые файлы:
Как указано в systemd.unit(5) , переменная %h заменяется домашней директорией пользователя, запускающего службу. Есть и другие переменные, которые учитываются на странице руководства systemd.
Чтение журнала
Журнал для пользователя может быть прочитан с помощью аналогичной команды:
Чтобы указать юнит, можно использовать
Обратите внимание, что journald не будет писать пользовательские журналы для пользователей с UID ниже 1000, вместо этого перенаправляя всё в системный журнал.
Временные файлы
/.local/share/user-tmpfiles.d/ в указанном порядке. Для использования этой функциональности требуется включить необходимые пользовательские юниты systemd для вашего пользователя:
Синтаксис конфигурационных файлов такой же, как и для всей системы. Для получения дополнительной информации смотрите справочные страницы systemd-tmpfiles(8) и tmpfiles.d(5) .
Xorg и systemd
Есть несколько способов запустить xorg в системных модулях. Ниже представлены два варианта: либо запустить новый пользовательский сеанс с процессом xorg, либо запустить xorg из пользовательской службы systemd.
Автоматический логин в Xorg без экранного менеджера
The factual accuracy of this article or section is disputed.
Reason: Спорная информация в оригинале: This setup ends up with two user D-Bus buses, one for the desktop, and an other for systemd. Why can't we use the systemd one alone? (Discuss in Talk:Systemd (Русский)/User (Русский))Эта опция запускает системный блок, который запускает сеанс пользователя с сервером xorg, а затем запускает обычный
/.xinitrc для запуска оконного менеджера и т.д.
Сеанс будет использовать собственный dbus демон, но различные утилиты systemd будут автоматически подключаться к экземпляру dbus.service . Наконец, enable службу xlogin@username для автоматического входа при загрузке.Сеанс пользователя полностью находится в области видимости systemd, и все в сеансе пользователя должно работать нормально.
Xorg как пользовательская служба systemd
Кроме того, Xorg можно запустить из службы пользователя systemd. Это хорошо, поскольку другие связанные с X юниты могут зависеть от xorg и т. д. Но с другой стороны, у этого есть некоторые недостатки, объясненные ниже.
xorg-server обеспечивает интеграцию с systemd двумя способами:
- Может быть запущен непривилегированным, делегируя управление устройствами logind (смотрите коммиты Hans de Goede коммит).
- Может быть превращен в сервис, активируемый сокетом (смотрите этот коммит). Это устраняет необходимость в systemd-xorg-launch-helper-gitAUR .
К сожалению, чтобы иметь возможность запускать xorg в непривилегированном режиме, он должен запускаться внутри сеанса. Итак, в данный момент недостаток запуска xorg в качестве пользовательской службы заключается в том, что он должен запускаться с привилегиями суперпользователя (как до 1.16) и не может использовать преимущества непривилегированного режима, представленного в 1.16.
Примечание: Это не является фундаментальным ограничением, налагаемым logind, но причина, по-видимому, заключается в том, что xorg нужно знать, какой сеанс взять на себя, и сейчас он получает эту информацию, вызывая logind's GetSessionByPID используя свой собственный pid в качестве аргумента. Смотрите this thread и xorg sources. Кажется вероятным, что xorg можно изменить, чтобы получить сеанс от tty, к которому он подключен, и затем он мог бы работать непривилегированным из пользовательской службы вне сеанса. Важно: В xorg 1.18 активация сокета, кажется, сломана. Клиент, вызывающий активацию, зависает. Смотрите вышестоящий отчет об ошибках [4]. В качестве временного обходного пути вы можете запустить сервер xorg без активации сокета, убедившись, что клиенты подключаются после задержки, поэтому сервер полностью запускается. Кажется, нет никакого удобного механизма, чтобы получить уведомление о запуске для X сервера.Вот как запустить xorg из пользовательского сервиса:
1. Заставить xorg работать с правами суперпользователя и для любого пользователя путем редактирования /etc/X11/Xwrapper.config
2. Добавить следующие юниты в
где $ - виртуальный терминал, на котором будет запущен xorg, либо прописанный в сервисном модуле, либо установленный в среде systemd с помощью
Примечание: xorg должен быть запущен на том же виртуальном терминале, где пользователь вошел в систему. В противном случае logind будет считать сеанс неактивным.3. Обязательно настройте переменную среды DISPLAY , как описано выше.
4. Затем, чтобы активировать сокет для xorg на дисплее 0 и tty 2, следует выполнить:
Теперь запуск любого X приложения автоматически запустит xorg на виртуальном терминале 2.
Переменная среды XDG_VTNR может быть установлена в среде systemd из .bash_profile , а затем можно запустить любое приложение X, включая диспетчер окон, как системный модуль, зависящий от xorg@0.socket .
Важно: В настоящее время запуск оконного менеджера в качестве пользовательской службы означает, что он работает работает за пределами сеанса, с проблемами, которые могут возникнуть: break the session. Однако, похоже, что разработчики systemd намерены сделать что-то подобное возможным. Смотрите [5] и [6]Некоторые случаи использования
Постоянный терминальный мультиплексор
This article or section is out of date.
Reason: Устаревшая информация в оригинале: Ссылается на user-session@.service вместо user@.service ; последний не содержит Conflicts=getty@tty1.service . (Discuss in Talk:Systemd (Русский)/User (Русский))Возможно, вы захотите, чтобы в сеансе пользователя по умолчанию использовался терминальный мультиплексор, например GNU Screen или Tmux, в фоновом режиме, а не для входа в сеанс оконного менеджера. Разделение входа в систему от входа в систему X, скорее всего, полезно только для тех, кто загружается с TTY, а не с экранным менеджером (в этом случае вы можете просто связать все, что вы запускаете, с myStuff.target).
Чтобы создать пользовательский сеанс такого типа, действуйте, как указано выше, но вместо создания wm.target создайте multiplexer.target:
cruft.target , как mystuff.target выше, должен запускать все, что, по вашему мнению, должно запускаться до запуска tmux или экрана (или что вы хотите запустить при загрузке независимо от времени), например сеанс демона GnuPG.
Затем вам нужно создать сервис для сеанса мультиплексора. Вот пример службы, использующей tmux в качестве примера и использующей сеанс gpg-agent, который записал свою информацию в /tmp/gpg-agent-info . Этот пример сеанса при запуске X также сможет запускать программы X, так как установлен DISPLAY.
Как только это будет сделано, systemctl --user enable tmux.service , multiplexer.target и любые сервисы, которые вы создали для запуска cruft.target , и вы должны быть готовы к работе! Активирован user-session@.service , как описано выше, но обязательно удалите Conflicts=getty@tty1.service из <
Оконный менеджер
Чтобы запустить оконный менеджер в качестве службы systemd, сначала необходимо запустить Xorg как пользовательскую службу systemd. В следующем примере мы будем использовать awesome (Русский):
Примечание: Раздел [Install] содержит часть WantedBy . При использовании systemctl --user enable он будет связывать это как/.config/systemd/user/wm.target.wants /window_manager.service , позволяя ему стартовать при входе в систему. Рекомендуется включить этот сервис, а не связывать его вручную.
Завершение процессов пользователя при выходе из системы
Arch Linux создает пакет systemd с помощью --without-kill-user-process , устанавливая KillUserProcesses равным no по умолчанию. Этот параметр предотвращает уничтожение пользовательских процессов, когда пользователь полностью выходит из системы. Чтобы изменить это поведение и убить все пользовательские процессы при выходе из системы, установите KillUserProcesses=yes в /etc/systemd/logind.conf .
Обратите внимание, что изменение этого параметра нарушает работу мультиплексоров терминала, таких как tmux и GNU Screen (Русский). Если вы измените этот параметр, вы все равно сможете использовать терминальный мультиплексор, используя systemd-run следующим образом:
Например, чтобы запустить screen , вы должны сделать:
Запущенные с помощью systemd-run процессы продолжат работу даже после выхода пользователя, если он залогинен в системе где-то ещё и служба user@.service всё ещё работает.
Решение проблем
Runtime directory '/run/user/1000' is not owned by UID 1000, as it should
Читайте также: