Советы и рекомендации
Программы настройки с графическим интерфейсом
systemadm — Графический поисковик юнитов systemd. Выводит список юнитов, возможна фильтрация по типу.
SystemdGenie — Утилита управления systemd на основе инструментов KDE.
Запуск сервисов после подключения к сети
Чтобы запустить сервис только после подключения к сети, добавьте такие зависимости в .service файле:
/etc/systemd/system/foo.service
... Wants=network-online.target After=network-online.target ...
Также должна быть включена служба ожидания сети того приложения, которое управляет сетью; только тогда будет соответствовать состоянию сети.
- В NetworkManager служба включается вместе с . Проверить состояние службы можно командой . Если служба не включена, то ещё раз.
- В случае netctl службу .
- Для пользователей systemd-networkd юнит включается вместе со службой ; проверьте это командой . Если нет, то .
Если служба отправляет DNS-запросы, она должна запускаться также после :
/etc/systemd/system/foo.service
... Wants=network-online.target After=network-online.target nss-lookup.target ...
Подробнее см. .
Чтобы цель работала как положено, должна быть служба, которая запускает её параметром и размещает себя перед ней (). Обычно это выполняет локальный .
Чтобы узнать, какие службы зависят от , выполните:
$ systemctl list-dependencies --reverse nss-lookup.target
Включение установленных юнитов по умолчанию
This article or section needs expansion.
Arch Linux поставляется с файлом , в котором указан параметр . Это означает, что systemctl preset отключает по умолчанию юниты и пользователь должен сам их включать после установки пакетов.
Если такое поведение не устраивает, создайте символическую ссылку на для переопределения файла конфигурации. Это заставит systemctl preset включать юниты новых пакетов — вне зависимости от типа — кроме указанных в других файлах из каталога настроек systemctl preset. Пользовательских юнитов это не касается. Подробнее смотрите .
Примечание: Политика включения всех юнитов по умолчанию может привести к проблемам, если в установленном пакете находится несколько взаимоисключающих юнитов. В этом случае в файле preset-настроек придётся явно указать, какие юниты включаться не должны. Подробнее смотрите .
Песочница для приложений
Юнит может быть использован в качестве песочницы для изоляции приложений и их процессов в виртуальном окружении. Systemd использует механизм namespaces, белые и чёрные списки capabilities, а также control groups для контейнеризации процессов при помощи настраиваемых окружений — см. .
Добавление к существующему юниту systemd функциональности песочницы обычно происходит методом проб и ошибок вкупе с использованием различных инструментов логирования — , и . В таких случаях имеет смысл предварительно поискать соответствующую документацию от разработчиков. В качестве отправной точки для поиска путей повышения безопасности изучите вывод команды:
$ systemd-analyze security юнит
Рекомендации по созданию песочницы с помощью systemd:
- Параметр определяет список разрешённых capabilities, но с его помощью можно также и запрещать некоторые capabilities для определённого юнита.
Уведомление о неработающих службах
Для уведомления о неудачном запуске службы используется директива в соответствующем файле службы или . Чтобы эта директива возымела эффект для всех служб одновременно, её необходимо добавть в drop-in файл верхнего уровня, см. .
Создайте drop-in верхнего уровня:
/etc/systemd/system/service.d/toplevel-override.conf
OnFailure=failure-notification@%n
Это добавит строку в файл каждой службы. Если какой-то_юнит завершится с ошибкой, запустится экземпляр службы для создания уведомления (или любой другой задачи, которая была назначена).
Создайте юнит-шаблон :
/etc/systemd/system/failure-notification@.service
Description=Send a notification about a failed systemd unit After=network.target Type=simple ExecStart=/путь/к/failure-notification.sh %i
После этого создайте сценарий , в котором определите, каким именно способом будет создаваться уведомление (mail, gotify, xmpp). Параметр будет заменён на название неудачно завершившегося юнита и будет передан сценарию в качестве аргумента.
Чтобы предотвратить регрессию экземпляров , создайте пустой файл drop-in настроек с именем, совпадающим с названием drop-in файла верхнего уровня (пустой файл «уровня служб» будет иметь приоритет над файлом «верхнего уровня»):
# mkdir -p /etc/systemd/system/failure-notification@.service.d # touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf
Управление модулями
До сих пор мы работали со службами и отображали информацию о модулях и файлах модулей, о которых знает . Однако мы можем узнать более конкретную информацию о модулях, используя некоторые дополнительные команды.
Отображение файла модуля
Чтобы отобразить файл модуля, который система загрузила в систему, можно использовать команду (она была добавлена в версию 209). Например, чтобы увидеть файл модуля демона-планировщика , можно ввести следующее:
Вывод — это файл модуля, известный выполняемому в настоящее время процессу
Это может быть важно, если вы недавно модифицировали файлы модуля или если вы переопределяете определенные опции во фрагменте файла модуля (мы рассмотрим это позже)
Отображение зависимостей
Чтобы увидеть дерево зависимостей модуля, можно использовать команду :
При этом отобразится иерархическая схема зависимостей, с которой необходимо работать, чтобы запустить интересуемый модуль. Зависимости в этом контексте включают те модули, которые либо требуются, либо желательны для модулей выше.
Рекурсивные зависимости отображаются только для модулей , которые указывают состояние системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг .
Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флаг . Другие полезные флаги и могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно, перед ними и после.
Проверка свойств модуля
Чтобы увидеть свойства более низкого уровня модуля, можно использовать команду . При этом будет выведен список свойств, заданных для указанного модуля с помощью формата :
Если вы хотите отобразить одно свойство, можно передать флаг с именем свойства. Например, чтобы увидеть конфликты, которые есть у модуля , можно ввести следующее:
Маскировка и снятие маскировки модулей
В разделе управления службами мы узнали, как остановить или отключить службу, но также имеет возможность отметить модуль как полностью незапускаемый, автоматически или вручную, связав его с . Это называется маскировкой модуля, и она возможна с помощью команды :
Это не позволит запустить службу Nginx автоматически или вручную, пока она замаскирована.
Если вы проверите , вы увидите, что служба теперь указана как замаскированная:
Если вы попытаетесь запустить службу, вы увидите следующее сообщение:
Чтобы снять маскировку модуля и сделать его доступным для использования снова, используйте команду :
Это вернет модуль в его предыдущее состояние, что позволит его запускать или включать.
Понимание логирования
- Прямая запись: некоторые сервисы записывают информацию напрямую в лог-файлы, даже некоторые важные сервисы, такие как веб-сервер Apache и файловый сервер Samba.
- rsyslogd: rsyslogd — это усовершенствование сервиса syslogd, который занимается централизованным управлением лог-файлов. Syslogd существует уже давно.
- journald: с введением systemd также был представлен сервис логирования journald. Этот сервис тесно интегрирован с systemd, что позволяет администраторам читать подробную информацию из journald, одновременно отслеживая состояние сервиса с помощью команды systemctl status.
Targets
Target – целевое состояние системы. Именно Target определяет, какие сервисы будут загружены и в каком порядке. Аналог из мира sysV init – runlevel. Основные виды таргетов:
- – отключение системы
- – режим восстановления, однопользовательский (init 1)
- – сетевой режим без графической оболочки, (init 3)
- – сетевой режим с графической оболочкой (init 5)
- – перезагрузка
- – аварийная командная строка, минимальный функционал
Цели могут наследоваться друг от друга. Например, graphical включает в себя загрузку всего, что есть multiuser + после этого – подгрузку графической оболочки.
Взаимодействие с целями:
Основы использования systemctl
Главная команда для отслеживания и контроля состояния systemd — команда systemctl. Некоторые из вариантов ее использования связаны с изучением состояния системы и управлением системой и службами.
Анализ состояния системы
Список запущенных юнитов:
$ systemctl
или:
$ systemctl list-units
Список неудач, — список юнитов, попытка запуска которых не удалась:
$ systemctl --failed
Доступные файлы юнитов можно посмотреть в директориях /usr/lib/systemd/system/ и /etc/systemd/system/ (второй каталог имеет приоритет). Вы можете увидеть список установленных файлов юнитов командой:
$ systemctl list-unit-files
Использование юнитов
Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).
При использовании systemctl обычно всегда необходимо указывать полное имя файла юнита, включая суффикс, например, sshd.socket. Однако, есть несколько сокращений для указания юнита в следующих командах systemctl:
- Ели вы не указали суффикс, systemctl предполагает, что это .service. Например, netctl и netctl.service будут трактоваться одинаково
- Точки монтирования будут автоматически преобразованы в соответствующий юнит .mount. Например, указание /home равнозначно home.mount
- Так же, как и точки монтирования, имена устройств автоматически преобразуются в соответствующий юнит .device, поэтому указание /dev/sda2 полностью соответствует юниту dev-sda2.device
Незамедлительно запустить юнит:
# systemctl start юнит
Незамедлительно остановить юнит:
# systemctl stop юнит
Перезапустить юнит:
# systemctl restart юнит
Запросить у юнита перезагрузку его настроек:
# systemctl reload юнит
Показать статус юнита, а также запущен он или нет:
$ systemctl status юнит
$ systemctl is-enabled юнит
# systemctl enable юнит
# systemctl disable юнит
Маскировать юнит, чтобы сделать невозможным его запуск:
# systemctl mask юнит
Снять маску юнита:
# systemctl unmask юнит
Показать страницу справочного руководства, связанного с юнитом (необходима поддержка этой функции в указанном файле юнита):
$ systemctl help юнит
Перезагрузить systemd для поиска новых или измененных юнитов:
# systemctl daemon-reload
Управление питанием
Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальной пользовательской сессии systemd-logind, и нет других активных сессий, приведенные ниже команды сработают и без привилегий суперпользователя. В противном случае (например, вследствие того, что другой пользователь вошел в систему в tty), systemd автоматически запросит у вас пароль суперпользователя.
Завершить работу и перезагрузить систему:
$ systemctl reboot
Завершить работу и выключить компьютер (с отключением питания):
$ systemctl poweroff
Перевести систему в ждущий режим:
$ systemctl suspend
Перевести систему в спящий режим:
$ systemctl hibernate
Перевести систему в режим гибридного сна (или suspend-to-both):
$ systemctl hybrid-sleep
Компоненты systemd
Некоторые (не все) составные части systemd:
- systemd-boot — простой для UEFI;
- systemd-firstboot — инициализация системных настроек при первой загрузке;
- systemd-homed — переносимые аккаунты пользователей;
- systemd-networkd — управление сетевыми настройками;
- systemd-nspawn — приложение для контейнеризации процессов;
- systemd-resolved — разрешение сетевых имён;
- — создание системных пользователей/групп и добавление пользователей в группы при установке пакетов и загрузке системы;
- systemd-timesyncd — синхронизация системных часов по сети;
- systemd/Журнал — системные логи;
- systemd/Таймеры — таймеры для управления событиями и службами, альтернатива cron.
systemd.mount — монтирование
systemd полностью отвечает за монтирование разделов и файловых систем, описанных в файле . преобразует записи из в юниты systemd; это выполняется при каждой загрузке системы, а также при перезагрузке конфигурации системного менеджера.
systemd расширяет возможности fstab и предлагает дополнительные опции монтирования. Они могут влиять на зависимости юнита монтирования: например, могут гарантировать, что монтирование выполняется только после подключения к сети или после монтирования другого раздела. Полный список опций монтирования systemd (обычно они имеют префикс ) описан в .
Примером этих опций может быть т.н. автомонтирование (здесь имеется в виду не автоматическое монтирование во время загрузки, а монтирование при появлении запроса от устройства). Подробнее смотрите .
Автомонтирование GPT-раздела
Требования:
- Корневой раздел должен быть на одном физическом диске с системным разделом EFI. Автомонтируемые разделы должны быть на одном физическом диске с корневым разделом. Очевидно, монтируемые разделы должны оказаться на одном диске и с ESP.
Совет: Автомонтирование разделов отключается изменением его или установкой атрибута раздела «do not mount» (бит 63), см. .
/var
Для автомонтирования раздела его PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой:
$ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id
Примечание: Утилита считывает machine ID из файла , поэтому вычислить PARTUUID до установки системы невозможно.
systemd-sysvcompat
Пакет (зависимость пакета ) содержит традиционный бинарный файл init. В системах под управлением systemd — символическая ссылка на исполняемый файл .
Кроме того, в этом пакете находятся 4 команды SysVinit — , , и . Это символические ссылки на , и их работа обусловлена логикой systemd. Подробнее см. .
systemd-tmpfiles — временные файлы
Утилита systemd-tmpfiles создает, удаляет и очищает непостоянные и временные файлы и каталоги. Она читает конфигурационные файлы из и , чтобы понять, что необходимо делать. Конфигурационные файлы в первом каталоге имеют приоритет над теми, что расположены во втором.
Конфигурационные файлы обычно предоставляются вместе с файлами служб и имеют названия вида . Например, демон Samba предполагает, что существует каталог с корректными правами доступа. Поэтому пакет поставляется в следующей конфигурации:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
Конфигурационные файлы также могут использоваться для записи значений при старте системы. Например, если вы используете для отключения пробуждения от устройств USB при помощи , вместо этого вы можете использовать следующий tmpfile:
/etc/tmpfiles.d/disable-usb-wake.conf
# Path Mode UID GID Age Argument w /proc/acpi/wakeup - - - - USBE
Подробнее смотрите и .
Примечание: Этот способ может не сработать для установки опций в , поскольку служба systemd-tmpfiles-setup может запуститься до того, как будут загружены соответствующие модули устройств. В этом случае при помощи команды вы можете проверить, имеет ли модуль параметр для установки необходимой опции, и установить эту опцию в в каталоге . В противном случае для установки верных атрибутов сразу при появлении устройства придется написать .
Самое необходимое
Предполагается, что у вас чистая установка CentOS 7 Minimal.
Установим зависимости:
Настроим часовой пояс:
Добавим EPEL-репозиторий:
Установим графическую оболочку:
Настроим системную локаль и клавиатуру:
Установим плагин Xfce для индикации и переключения раскладки клавиатуры:
Добавить плагин на панель инструментов Xfce нужно будет вручную.
Установим RDP-сервер:
Отключим Xnvc и оптимизируем скорость xRDP:
Зачем отключаем Xnvc? В Xnvc проблемы с русской раскладкой.
Закомментируйте секцию .
В секции установите настройки:
Ниже будет рекомендация отключить эффекты для окон Xfce (п. 12) и установить простой сплошной фон для рабочего стола (п. 13).
Сконфигурируем клавиатуру для xRDP:
Замените содержимое файла на следующее:
Опционально: разрешите пользователям создание множественных сессий и активируйте автозакрытие сессий отключившихся пользователей.
Такое поведение требуется в некоторых специфических ситуациях
Скорее всего, именно вам оно не понадобится.
Установите и.
Важно: некоторые программы (например, Chrome) в такой среде не будут правильно работать (множество инстансов под одним пользователям — часто сложная ситуация).
Кстати, среди популярных браузеров множественные инстансы под одним пользователем поддерживает Firefox. Предполагается режим и создание/выбор отдельного профиля под каждый экземпляр программы.
Полезно сразу отредактировать строку запуска Firefox в системном меню:
Замените
на
Настройте файрвол в зависимости от требуемого уровня безопасности.
Если сервер имеет внешний публичный IP и вы бы хотели подключаться к удаленному рабочему столу напрямую, используйте следующую команду:
Более безопасный вариант — VPN (в данной статье не рассматривается).
Отключите эффекты для окон Xfce.
См. меню «Настройки» → «Диспетчер окон (дополнительно)» → «Эффекты».
Установите сплошной цветовой фон для рабочего стола.
См. меню «Настройки» → «Рабочий стол».
Некоторые случаи использования
Постоянный терминальный мультиплексор
This article or section is out of date.
Возможно, вы захотите, чтобы в сеансе пользователя по умолчанию использовался терминальный мультиплексор, например GNU Screen или Tmux, в фоновом режиме, а не для входа в сеанс оконного менеджера. Разделение входа в систему от входа в систему X, скорее всего, полезно только для тех, кто загружается с TTY, а не с экранным менеджером (в этом случае вы можете просто связать все, что вы запускаете, с myStuff.target).
Чтобы создать пользовательский сеанс такого типа, действуйте, как указано выше, но вместо создания wm.target создайте multiplexer.target:
Description=Terminal multiplexer Documentation=info:screen man:screen(1) man:tmux(1) After=cruft.target Wants=cruft.target Alias=default.target
, как выше, должен запускать все, что, по вашему мнению, должно запускаться до запуска tmux или экрана (или что вы хотите запустить при загрузке независимо от времени), например сеанс демона GnuPG.
Затем вам нужно создать сервис для сеанса мультиплексора. Вот пример службы, использующей tmux в качестве примера и использующей сеанс gpg-agent, который записал свою информацию в . Этот пример сеанса при запуске X также сможет запускать программы X, так как установлен DISPLAY.
Description=tmux: A terminal multiplixer Documentation=man:tmux(1) After=gpg-agent.service Wants=gpg-agent.service Type=forking ExecStart=/usr/bin/tmux start ExecStop=/usr/bin/tmux kill-server Environment=DISPLAY=:0 EnvironmentFile=/tmp/gpg-agent-info WantedBy=multiplexer.target
Как только это будет сделано, , и любые сервисы, которые вы создали для запуска , и вы должны быть готовы к работе! Активирован , как описано выше, но обязательно удалите из {{ic|user-session@.service} }, поскольку ваш пользовательский сеанс не будет принимать TTY. Поздравляем! У вас есть работающий терминальный мультиплексор и некоторые другие полезные программы, готовые к запуску при загрузке!
Оконный менеджер
Чтобы запустить оконный менеджер в качестве службы systemd, сначала необходимо запустить . В следующем примере мы будем использовать awesome (Русский):
~/.config/systemd/user/awesome.service
Description=Awesome window manager After=xorg.target Requires=xorg.target ExecStart=/usr/bin/awesome Restart=always RestartSec=10 WantedBy=wm.target
Примечание: Раздел содержит часть . При использовании он будет связывать это как , позволяя ему стартовать при входе в систему. Рекомендуется включить этот сервис, а не связывать его вручную.
Понимание ролей rsyslogd и journald
journalctlrsyslogd добавляет к нему некоторые сервисы. В частности, он заботится о записи данных журнала в определенные файлы (которые будут постоянными между перезагрузками) и позволяет настраивать удаленные журналы и серверы журналов.
- Файлы в /var/log, которые пишутся rsyslogd, должны контролироваться.
- Команда journalctl может использоваться для получения более подробной информации из журнала.
- Для краткого обзора последних значимых событий, которые были зарегистрированы модулями systemd через journald, администраторы могут использовать команду systemctl status <unit>. Эта команда показывает состояние сервисов, а также последние пару строк, которые были логированы. В листинге 1 показан пример, в котором эта команда четко указывает, что пошло не так при запуске сервиса.
Чтение лог-файлов
journalctlless
log-файл
Объяснение
/var/log/messages
Наиболее часто используемый файл журнала, это общий файл журнала, в который записывается большинство сообщений.
/var/log/dmesg
Содержит сообщения журнала ядра.
/var/log/secure
Содержит сообщения, связанные с аутентификацией.
/var/log/boot.log
Сообщения, связанные с запуском системы.
/var/log/audit/audit.log
Содержит сообщения аудита. SELinux пишет в этот файл.
/var/log/maillog
Сообщения, связанные с почтой.
/var/log/samba
Предоставляет файлы журналов для сервиса Samba
Обратите внимание, что по умолчанию Samba не управляется через rsyslog, а записывается непосредственно в каталог /var/log.
/var/log/sssd
Содержит сообщения, записанные сервисом sssd, который играет важную роль в процессе аутентификации.
/var/log/cups
Содержит сообщения, сгенерированные службой печати CUPS.
/var/log/httpd/
Каталог, содержащий лог-файлы, которые записываются веб-сервером Apache. Обратите внимание, что Apache пишет сообщения в эти файлы напрямую, а не через rsyslog.
Понимание содержимого лог-файла
Дата и время: каждое сообщение начинается с отметки времени. В целях фильтрации метка времени записывается как военное время.
Хост: хост, с которого отправлено сообщение
Это важно, потому что rsyslogd также может быть настроен для обработки удаленных логов.
Имя службы или процесса: имя сервиса или процесса, сгенерировавшего сообщение.
Содержимое сообщения: содержимое сообщения, которое содержит точное сообщение, которое было зарегистрировано.
lesstail -ftail -f /var/log/messages
# Как настроить статический IP-адрес в CentOS 7
minimalifconfig
-bash: ifconfig: command not found
net-tools
# yum -y install net-tools.x86_64
ifconfig
# ifconfig eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.0.160 netmask 255.255.255.0 broadcast 192.168.146.255 inet6 fe80::250:56ff:fe24:ccd6 prefixlen 64 scopeid 0x20<link> ether 00:50:56:24:cc:d6 txqueuelen 1000 (Ethernet) RX packets 210 bytes 19072 (18.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 71 bytes 11531 (11.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 4 bytes 340 (340.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4 bytes 340 (340.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ip addr:
# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:24:cc:d6 brd ff:ff:ff:ff:ff:ff inet 172.16.0.160/24 brd 192.168.146.255 scope global dynamic eno16777736 valid_lft 1672sec preferred_lft 1672sec inet6 fe80::250:56ff:fe24:ccd6/64 scope link valid_lft forever preferred_lft forever
# cat ifcfg-eno16777736 TYPE=Ethernet BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME=eno16777736 UUID=dc1636be-5281-4a07-8681-fcdc8b161c8c DEVICE=eno16777736 ONBOOT=no PEERDNS=yes PEERROUTES=yes
BOOTPROTOBOOTPROTO=none
и дописать:
Указать ДНС:
DNS1=8.8.8.8
Прописываем IP:
IPADDR0=172.16.0.30
Указываем нужную маску:
PREFIX0=24
Прописываем шлюз по умолчанию:
GATEWAY0=172.16.0.1
И чтобы у нас сетевая карта «поднималась» при запуске ОС, необходимо в этом файле найти параметр ONBOOT и прописать ему yes.
В итоге у нас должно получится что то типа этого:
Для немедленного применения изменений перезапустим сеть:
# /etc/init.d/network restart
# ifconfig eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.0.30 netmask 255.255.255.0 broadcast 172.16.0.255 ether 00:50:56:24:cc:d6 txqueuelen 1000 (Ethernet) RX packets 5039 bytes 360189 (351.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1015 bytes 181656 (177.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Общая идея
Одна из целей журнальной системы заключается в централизации управления журналами вне зависимости от источника сообщений. Поскольку существенная часть процесса загрузки и управления службами выполняется процессом , имеет смысл стандартизировать сбор данных для журналов и доступ к ним. Демон собирает данные из всех доступных источников и сохраняет их в двоичном формате для удобного и динамичного управления ими.
Это дает нам ряд существенных преимуществ. Взаимодействуя с данными через одну утилиту, администраторы могут динамически выводить данные журнала в соответствии с их потребностями. Это могут быть как простые задачи, такие как просмотр данных предыдущей загрузки системы, так и более сложные задачи, например, комбинирование записей журналов двух связанных служб для устранения коммуникационной проблемы.
Хранение данных журнала в двоичном формате также означает, что данные можно отображать в произвольном виде в зависимости от того, что требуется в текущий момент. Например, для каждодневного управления журналами вы можете использовать стандартный формат , но если вы захотите составить график перебоев в работе служб, вы можете вывести все записи в формате объектов JSON для экспорта в приложение составления графиков. Поскольку данные не записываются на диск в формате обычного текста, их не нужно будет конвертировать, если вам потребуется другой формат вывода.
Журнальную систему можно использовать вместе с существующей реализацией , или в качестве функциональной замены , если вам это потребуется. Хотя журнальная система способна удовлетворить большинство потребностей администратора, ее также можно использовать в качестве дополнения к существующим механизмам ведения журнала. Например, вы можете использовать централизованный сервер для компиляции данных с нескольких серверов, но при этом также чередовать журналы нескольких служб одной системы с журналом . Объединив эти технологии, вы можете выполнить обе задачи.
Решение проблем
Неудачно запущенные службы
Следующая команда найдёт все службы, которые не смогли выполнить запуск:
$ systemctl --state=failed
Чтобы определить причину, по которой служба не запустилась, необходимо изучить записи её логов. Подробнее см. .
Диагностика службы
Если какая-либо служба systemd ведет себя не так, как ожидается, и вы хотите получить дополнительную информацию о том, что происходит, присвойте переменной окружения значение . Например, чтобы запустить демон systemd-networkd в режиме отладки:
Добавьте для службы:
Environment=SYSTEMD_LOG_LEVEL=debug
Или, как вариант, пропишите переменную окружения вручную:
# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
После этого systemd-networkd и следите за журналом службы с помощью опции /.
Время загрузки системы увеличивается с течением времени
После использования некоторые пользователи заметили, что время загрузки системы значительно увеличилось. После использования NetworkManager запускался необычно долго.
Проблема связана с тем, что файл стал слишком большим. При этом также может уменьшаться скорость работы других команд, например, или . Для решения проблемы можно удалить все файлы из каталога журнала (в идеале — сделав где-нибудь резервные копии, хотя бы временно), а затем размер журнала.
systemd-tmpfiles-setup.service не запускается во время загрузки
Начиная с версии Systemd 219, определяет ACL-атрибуты для каталогов в и, следовательно, требует поддержки ACL для той файловой системы, в которой находится журнал.
Отключение emergency mode на удалённой машине
Вам может понадобиться отключить emergency mode на удалённой машине, например на виртуальных машинах Azure или Google Cloud. Это связано с тем, что в случае ухода системы в emergency mode она отключится от сети и лишит вас возможности подключения к ней.
Для отключения этого режима и .
Временные файлы
systemd-tmpfiles позволяет пользователям управлять нестабильными и временными файлами и каталогами так же, как общесистемным способом (см. ). Пользовательские файлы конфигурации считываются из и в указанном порядке. Для использования этой функциональности требуется включить необходимые пользовательские юниты systemd для вашего пользователя:
$ systemctl --user enable systemd-tmpfiles-setup.service systemd-tmpfiles-clean.timer
Синтаксис конфигурационных файлов такой же, как и для всей системы. Для получения дополнительной информации смотрите справочные страницы и .
