systemd (Русский)
Ссылки по теме
Цитата с веб-страницы проекта:
- systemd - менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации, использует сокеты и активацию D-Bus для запускаемых служб, предлагает запуск демонов по необходимости, отслеживает процессы при помощи контрольных групп Linux, поддерживает мгновенные снимки и восстановление состояния системы, монтирование и точки монтирования, а также внедряет основанную на зависимостях логику контроля процессов сложных транзакций.
Contents
- 1 Основы использования systemctl
- 2 Написание файлов юнитов
- 3 Цели
- 4 Временные файлы
- 5 Таймеры
- 6 Журнал
- 7 Оптимизация
-
8 Решение проблем
- 8.1 Изучение ошибок systemd
- 8.2 Диагностика проблем с загрузкой системы
- 8.3 Диагностика проблем в работе определенной службы
- 8.4 Выключение/перезагрузка происходят ужасно долго
- 8.5 По-видимому, процессы с кратким сроком жизни не оставляют записей в логах
- 8.6 Отключение журналирования аварийных дампов памяти приложений
- 8.7 Сообщение об ошибке при перезагрузке или выключении
- 8.8 Время загрузки системы увеличивается с течением времени
- 9 Смотрите также
Основы использования systemctl
Главная команда для отслеживания и контроля состояния systemd - команда systemctl. Некоторые из вариантов ее использования связаны с изучением состояния системы и управлением системой и службами. Обратитесь к странце руководства man 1 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. Например,
netcfg
иnetcfg.service
будут трактоваться одинаково - Точки монтирования будут автоматически преобразованы в соответствующий юнит .mount. Например, указание
/home
равнозначноhome.mount
- Так же, как и точки монтирования, имена устройств автоматически преобразуются в соответствующий юнит .device, поэтому указание
/dev/sda2
полностью соответствует юнитуdev-sda2.device
Для получения дополнительной информации смотрите страницу справочного руководства man systemd.unit
.
Незамедлительно запустить юнит:
# systemctl start юнит
Незамедлительно остановить юнит:
# systemctl stop юнит
Перезапустить юнит:
# systemctl restart юнит
Запросить у юнита перезагрузку его настроек:
# systemctl reload юнит
Показать статус юнита, а также запущен он или нет:
$ systemctl status юнит
Проверить, включен ли юнит в автозапуск при загрузке системы:
$ systemctl is-enabled юнит
Включить юнит в автозапуск при загрузке системы:
# systemctl enable юнит
Убрать юнит из автозапуска при загрузке системы:
# systemctl disable юнит
Показать страницу справочного руководства, связанного с юнитом (необходима поддержка этой функции в указанном файле юнита):
$ 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 вдохновлен файлами .desktop XDG Desktop Entry Specification, а они, в свою очередь - файлами .ini Microsoft Windows. Файлы юнитов загружаются из двух мест. Вот они по приоритету от низшего к высшему:
-
/usr/lib/systemd/system/
: юниты, предоставляемые пакетами при их установке -
/etc/systemd/system/
: юниты, устанавливаемые системным администратором
Обработка зависимостей
В случае использования systemd зависимости могут быть указаны правильным построением файлов юнитов. Наиболее частый случай -- юниту A требуется, чтобы юнит B был запущен перед тем, как запустится сам юнит A. В этом случае добавьте строки Requires=B
и After=B
в секцию [Unit]
файла службы A. Если подобная зависимость не является обязательной, взамен указанных выше добавьте, соответственно, строки Wants=B
и After=B
. Обратите внимание, что Wants=
и Requires=
не подразумевают After=
, что означает, что если After=
не определено, два юнита будут запущены параллельно друг другу.
Обычно зависимости указываются в файлах служб, а не в целевых юнитах. Например, network.target потребуется любой службе, которая связана с настройкой ваших сетевых интерфейсов, поэтому в любом случае определите загрузку вашего пользовательского юнита после запуска network.target.
Типы служб
Существует несколько различных типов запуска служб, которые надо иметь в виду при написании пользовательского файла службы. Тип определяется параметром Type=
в секции [Service]
:
-
Type=simple
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы. Исключение - активация сокета -
Type=forking
: systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Используйте данный тип для запуска классических демонов за исключением тех случаев, когда, как вам известно, в таком поведении процесса нет необходимости. Вам следует также определитьPIDFile=
, чтобы systemd могла отслеживать основной процесс -
Type=oneshot
: полезен для скриптов, которые выполняют одно задание и завершаются. Вам может понадобиться также установить параметрRemainAfterExit=yes
, чтобы systemd по-прежнему считала процесс активным, даже после его завершения -
Type=notify
: идентичен параметруType=simple
, но с той оговоркой, что демон пошлет systemd сигнал о своей готовности. Эталонная реализация данного уведомления представлена в libsystemd-daemon.so -
Type=dbus
: сервис считается находящимся в состоянии готовности, когда определенноеBusName
появляется в системной шине DBus -
Type=idle
: в этом случае поведение очень похоже наType=simple
, но запуск исполняемого файла службы отложен до тех пор, пока не будут обработаны другие задания. Этот тип можно использовать во избежание наложения вывода запускаемых служб на статусные сообщения в консоли
Обратитесь к руководству man systemd.service
для получения более детального объяснения.
Редактирование предоставленных пакетами файлов юнитов
Для того, чтобы отредактировать предоставляемый пакетом файл юнита, вы можете создать каталог с названием /etc/systemd/system/unit.d/
(например, /etc/systemd/system/httpd.service.d/
) и поместить в него файлы *.conf, чтобы переопределить или добавить новые параметры. systemd просмотрит эти файлы *.conf и применит их настройки поверх настроек поставляемого исходного юнита. Например, если вы просто хотите добавить в службу дополнительную зависимость, вы можете создать следующий файл:
/etc/systemd/system/юнит.d/customdependency.conf
[Unit] Requires=новая зависимость After=новая зависимость
Другой пример: чтобы заменить указание на выполнение команды ExecStart
юнита, имеющего тип, отличный от oneshot
, используйте следующие строки:
/etc/systemd/system/юнит.d/customexec.conf
[Service] ExecStart= ExecStart=новая команда
Заметьте, что ExecStart
должен быть очищен перед повторным назначением ([1]).
Еще один пример - автоматический перезапуск службы:
/etc/systemd/system/юнит.d/restart.conf
[Service] Restart=always RestartSec=30
Затем выполните следующие команды для того, чтобы изменения вступили в силу:
# systemctl daemon-reload # systemctl restart юнит
В качестве другого варианта вы можете скопировать старый файл юнита из каталога /usr/lib/systemd/system/
в /etc/systemd/system/
и применить свои изменения там. Файл юнита в /etc/systemd/system/
всегда имеет приоритет и переопределяет настройки такого же юнита из каталога /usr/lib/systemd/system/
. Обратите внимание, что поставляемый исходный юнит в директории /usr/lib/
изменяется при обновлении пакета, и эти изменения не будут автоматически применены к вашему отредактированному файлу юнита из /etc/
. Дополнительно вы должны вручную выполнить команду systemctl reenable юнит
, чтобы изменения вступили в силу. Тем не менее, рекомендуется вместо данного варианта использовать описанный выше метод с файлами *.conf
.
Цели
systemd использует цели (англ. target), которые выполняют ту же задачу, что и уровни запуска (англ. runlevel), но действуют немного по-другому. Каждая цель поименована (т.е. имеет собственное имя, а не номер) и, как предполагается, предназначена для конкретных задач; возможно иметь в одно и то же время активными несколько таких целей. Некоторые цели реализованы так, что наследуют все службы других целей, добавляя к ним свои. В systemd имеются также цели, которые имитируют общие уровни запуска SystemVinit, поэтому вы можете переключаться между целевыми юнитами, используя привычную команду telinit RUNLEVEL
.
Получение информации о текущих целях
При использовании systemd для этого предназначена следующая команда (заменяющая runlevel
):
$ systemctl list-units --type=target
Создание пользовательской цели
Уровни запуска, по которым расписаны конкретные задачи при установке ванильной Fedora по умолчанию - 0, 1, 3, 5 и 6 - имеют соответствие 1:1 с конкретными целями systemd. К сожалению, не существует хорошего способа сделать то же самое для определяемых пользователем уровней, таких как 2 и 4. Их использование предполагает, что вы создаете новый именованный целевой юнит systemd наподобие /etc/systemd/system/ваша цель
, который берет за основу один из существующих уровней запуска (взгляните, например, на /usr/lib/systemd/system/graphical.target
), создаете каталог /etc/systemd/system/ваша цель.wants
, а после этого - символические ссылки на дополнительные службы из директории /usr/lib/systemd/system/
, которые вы хотите включить при загрузке.
Таблица целей
Уровнень запуска SysV | Цель systemd | Примечания |
---|---|---|
0 | runlevel0.target, poweroff.target | Выключить систему |
1, s, single | runlevel1.target, rescue.target | Однопользовательский уровень запуска |
2, 4 | runlevel2.target, runlevel4.target, multi-user.target | Уровни запуска, определенные пользователем/специфичные для узла. По умолчанию соответствует уровню запуска 3 |
3 | runlevel3.target, multi-user.target | Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть |
5 | runlevel5.target, graphical.target | Многопользовательский режим с графикой. Обычно эквивалентен запуску всех служб на уровне 3 и графического менеджера входа в систему |
6 | runlevel6.target, reboot.target | Перезагрузка |
emergency | emergency.target | Аварийная оболочка |
Изменение текущей цели
В systemd цели доступны посредством целевых юнитов. Вы можете изменить их командой:
# systemctl isolate graphical.target
Данная команда изменит только лишь текущую цель и не повлияет на следующую загрузку системы. Она соответствует командам Sysvinit вида telinit 3
и telinit 5
.
Изменение цели загрузки по умолчанию
Стандартная цель - default.target, которая по умолчанию является псевдонимом graphical.target (примерно соответствующего прежнему уровню запуска 5). Для изменения цели загрузки по умолчанию добавьте один из следующих параметров ядра в ваш загрузчик:
-
systemd.unit=multi-user.target
(что примерно соответствует прежнему уровню запуска 3) -
systemd.unit=rescue.target
(что примерно соответствует прежнему уровню запуска 1)
Другой способ - оставить загрузчик без изменений, а изменить целевой юнит по умолчанию - default.target. Это делается с использованием systemctl:
# systemctl set-default multi-user.target
Чтобы иметь возможность перезаписать ранее установленную default.target, используйте опцию force:
# systemctl set-default -f multi-user.target
Эффект от применения данной команды выводится через systemctl. Символическая ссылка на новый целевой юнит по умолчанию создается в директории /etc/systemd/system/default.target
.
Временные файлы
"systemd-tmpfiles создает, удаляет и очищает непостоянные и временные файлы и каталоги". Он читает конфигурационные файлы из /etc/tmpfiles.d/
и /usr/lib/tmpfiles.d/
, чтобы понять, что ему следует делать. Конфигурационные файлы в первом каталоге имеют приоритет над теми, что расположены во втором.
Конфигурационные файлы обычно предоставляются вместе с файлами служб и имеют названия вида /usr/lib/tmpfiles.d/программа.conf
. Например, демон Samba предполагает, что существует каталог /run/samba
с корректными правами доступа. Поэтому пакет samba поставляется в следующей конфигурации:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
Конфигурационные файлы также могут использоваться для записи значений при старте системы. Например, если вы используете /etc/rc.local
для отключения пробуждения от устройств USB при помощи echo USBE > /proc/acpi/wakeup
, вместо этого вы можете использовать следующий tmpfile:
/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE
Для получения дополнительной информации смотрите страницы справочного руководства (man) systemd-tmpfiles(8)
и tmpfiles.d(5)
.
Таймеры
Таймер - это файл конфигурации юнита, имя которого заканчивается на .timer. Он расшифровывает информацию о таймере, контролируемом при помощи systemd, для активации в определенное время. Смотрите статью systemd/Tаймеры.
Журнал
systemd имеет собственную систему ведения логов, названную журналом (journal). В связи с этим больше не требуется запускать демон syslog
. Для чтения логов используйте команду:
# journalctl
В Arch Linux каталог /var/log/journal/
является частью пакета systemd, и по умолчанию (когда в конфигурационном файле /etc/systemd/journald.conf
параметр Storage=
имеет значение auto
) журнал записывается именно в него. В случае, если вы или какая-либо программа удалили его, systemd не воссоздаст ее автоматически , но при следующем обновлении systemd эта директория будет восстановлена. До восстановления данной директории логи будут записываться в каталог /run/systemd/journal
. Это означает, что логи будут потеряны при перезагрузке.
Фильтрация вывода
journalctl позволяет фильтровать вывод по особым полям. Помните, что, если должно быть отражено большое количество сообщений или необходима фильтрация в большом промежутке времени, вывод этой команды может быть отложен на какое-то время.
Примеры:
- Показать все сообщения с момента текущей загрузки системы:
# journalctl -b
Однако, пользователи часто интересуются сообщениями не для текущей, а для предыдущей загрузки (например, если произошел невосстановимый сбой системы). Это возможно, если задать параметр флагу-b
:journalctl -b -0
покажет сообщения с момента текущей загрузки,journalctl -b -1
- предыдущей загрузки,journalctl -b -2
- следующей за предыдущей, и т.д. Для просмотра полного описания смотрите страницу справочного руководстваman 1 journalctl
: имеется гораздо более мощная семантика - Показать все сообщения, начиная с какой-либо даты (и, если хотите, времени):
# journalctl --since="2012-10-30 18:17:16"
- Показать все сообщения за последние 20 минут:
# journalctl --since "20 min ago"
- Показывать новые сообщения:
# journalctl -f
- Показать все сообщения для конкретного исполняемого файла:
# journalctl /usr/lib/systemd/systemd
- Показать все сообщения для конкретного процесса:
# journalctl _PID=1
- Показать все сообщения для конкретного юнита:
# journalctl -u netcfg
- Показать кольцевой буфер ядра:
# journalctl -k
Для получения дополнительной информации смотрите страницы справочного руководства man 1 journalctl
и man 7 systemd.journal-fields
или пост в блоге Lennart'а.
Ограничение размера журнала
Если журнал сохраняется при перезагрузке, его размер по умолчанию ограничен значением в 10% от объема соответствующей файловой системы. Например, для директории /var/log/journal
, расположенной на корневом разделе в 50 Гбайт, максимальный размер журналируемых данных составит 5 Гбайт. Максимальный объем постоянного журнала можно контролировать при помощи значения SystemMaxUse
в конфигурационном файле /etc/systemd/journald.conf
, поэтому для ограничения его объемом, например, в 50 Mбайт раскомментируйте и отредактируйте соответствующую строку:
SystemMaxUse=50M
Для получения дополнительной информации обратитесь к странице справочного руководства man journald.conf
.
Journald в связке с классическим демоном syslog
Совместимость с классической реализацией syslog можно обеспечить, заставив systemd направлять все сообщения через сокет /run/systemd/journal/syslog
. Чтобы дать возможность демону syslog работать вместе с журналом systemd, следует привязать данный демон к указанному сокету вместо /dev/log
(официальное сообщение). Пакетом syslog-ng из репозиториев автоматически предоставляется необходимая конфигурация.
В настоящий момент (systemd версии 216) в journald.conf
для перенаправления сообщений в сокет по умолчанию установлено значение no
("нет"). Это значит, что для того, чтобы использовать syslog-ng совместно с journald, в файле /etc/systemd/journald.conf
необходимо указать значение ForwardToSyslog=yes
. Для получения дополнительной информации смотрите раздел Обзор.
Если взамен вы используете rsyslog, нет необходимости менять эту настройку, поскольку rsyslog забирает сообщения из журнала самостоятельно.
Отправка вывода journald на /dev/tty12
В файле /etc/systemd/journald.conf
включите следующее:
ForwardToConsole=yes TTYPath=/dev/tty12 MaxLevelConsole=info
Перезапустите journald при помощи команды:
# systemctl restart systemd-journald
Оптимизация
Анализ процесса загрузки
Использование systemd-analyze
Systemd предоставляет инструмент под названием systemd-analyze
, позволяющий проанализировать процесс загрузки вашей системы, чтобы можно было увидеть, какие файлы юнитов тормозят загрузку. Соответственно, вы можете оптимизировать вашу систему. Для использования данного инструмента вам потребуется установить пакеты python2-cairo и python2-gobject.
Чтобы увидеть, сколько времени было потрачено на подготовку пространства ядра и пространства пользователя во время загрузки, просто выполните команду:
$ systemd-analyze
Чтобы увидеть список запускаемых файлов юнитов, отсортированный по потраченному каждым из них на загрузку времени, выполните команду:
$ systemd-analyze blame
Вы также можете создать файл SVG, показывающий процесс загрузки в графическом виде, наподобие Bootchart:
$ systemd-analyze plot > plot.svg
Использование systemd-bootchart
Bootchart объединен с systemd с 17 октября 2012 года и вы можете использовать его для загрузки также, как и оригинальный bootchart. Добавьте следующие команду к строке инициализации ядра:
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
Использование bootchart2
Вы также можете использовать версию bootchart для визуализации последовательности при загрузке системы. Из-за невозможности использовать стандартные установки bootchart (так как нельзя добавить в командную строку ядра вторую запись init), вам придется воспользоваться пакетом bootchart2-gitAUR из AUR, поставляемым с недокументированным сервисом systemd. После установки bootchart2 выполните команду:
# systemctl enable bootchart
Обратитесь к документации bootchart (англ.) за дальнейшей и детализированной информацией об использовании данной версии bootchart.
Решение проблем
Изучение ошибок systemd
В качестве примера мы изучим ошибки службы systemd-modules-load
:
1. Давайте найдем службы systemd, которые не смогли запуститься:
$ systemctl --state=failed
systemd-modules-load.service loaded failed failed Load Kernel Modules
2. Хорошо, мы обнаружили проблему в службе systemd-modules-load
и хотим узнать больше:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago Docs: man:systemd-modules-load.service(8). man:modules-load.d(5) Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
Если вы не увидите в списке Process ID
, просто перезапустите службу при помощи команды systemctl restart systemd-modules-load
3. Теперь у нас есть id процесса (PID) для более детального изучения ошибки. Введите следующую команду с правильным Process ID
(в данном примере это 15630):
$ journalctl -b _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. -- Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp' Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'
4. Мы видим, что некоторые конфигурационные файлы модулей ядра имеют неверные настройки. В этом случае мы взглянем на эти настройки в каталоге /etc/modules-load.d/
:
$ ls -Al /etc/modules-load.d/
... -rw-r--r-- 1 root root 79 1. Dez 2012 blacklist.conf -rw-r--r-- 1 root root 1 2. Mär 14:30 encrypt.conf -rw-r--r-- 1 root root 3 5. Dez 2012 printing.conf -rw-r--r-- 1 root root 6 14. Jul 11:01 realtek.conf -rw-r--r-- 1 root root 65 2. Jun 23:01 virtualbox.conf ...
5. Сообщение об ошибке Failed to find module 'blacklist usblp'
должно относиться к неправильной настройке в файле blacklist.conf
. Давайте закомментируем настройку, вставив хэш-символ # перед каждой опцией, найденной на шаге 3:
/etc/modules-load.d/blacklist.conf
# blacklist usblp # install usblp /bin/false
6. Теперь попробуйте запустить systemd-modules-load
:
$ systemctl start systemd-modules-load
Если все прошло успешно, ничего не отобразится. Если же вы видите какие-либо ошибки, вернитесь к шагу 3 и используйте новый PID для устранения оставшихся ошибок.
Если все хорошо, вы можете удостовериться, что служба успешно запустилась, при помощи команды:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.
Чаще всего подобные проблемы можно решить так, как показано выше. Для дальнейшего изучения этого вопроса взгляните на раздел #Диагностика проблем с загрузкой системы.
Диагностика проблем с загрузкой системы
Загрузитесь с этими параметрами ядра:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
Дополнительная информация по отладке.
Диагностика проблем в работе определенной службы
Если какая-либо служба systemd ведет себя не так, как ожидается, и вы хотите получить дополнительную информацию о том, что происходит, присвойте переменной окружения SYSTEMD_LOG_LEVEL
значение debug
. Например, чтобы запустить демон systemd-networkd в режиме отладки:
# systemctl stop systemd-networkd # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
В качестве альтернативы можно временно отредактировать файл службы для получения подробного вывода. Например:
/lib/systemd/system/systemd-networkd.service
[Service] ... Environment=SYSTEMD_LOG_LEVEL=debug ....
Если вы знаете, что в дальнейшем вам по-прежнему будет нужна эта отладочная информация, добавьте переменную обычным способом.
Выключение/перезагрузка происходят ужасно долго
Если процесс выключения занимает очень долгое время (или, по-видимому, зависает), то, вероятно, виновата служба, которая не завершает свою работу. systemd ожидает некоторое время, пока каждая служба завершит свою работу самостоятельно, и только потом пытается принудительно завершить (kill) ее. Если вы столкнулись с такой проблемой, обратитесь к данной статье (англ.).
По-видимому, процессы с кратким сроком жизни не оставляют записей в логах
Если команда journalctl -u foounit
не показывает вывода для службы с коротким сроком жизни, вместо нее обратитесь к PID. Например, если загрузка службы systemd-modules-load.service
завершилась неудачно и команда systemctl status systemd-modules-load
показывает, что она была запущена с PID 123, то вы сможете посмотреть вывод процесса в журнале под данным PID, то есть командой journalctl -b _PID=123
. Такие поля метаданных для журнала, как _SYSTEMD_UNIT и _COMM, собираются асинхронно и зависят от директории /proc
в случае с действующими процессами. Исправление этой ситуации требует внесения исправлений в ядро для обеспечения предоставления этих данных через сокет, наподобие SCM_CREDENTIALS.
Отключение журналирования аварийных дампов памяти приложений
Добавьте в файл /etc/systemd/coredump.conf
такую строку:
Storage=none
и перезагрузите систему.
Сообщение об ошибке при перезагрузке или выключении
cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd"
Для получения объяснения смотрите эту ветку.
watchdog watchdog0: watchdog did not stop!
Для получения объяснения смотрите эту ветку.
Время загрузки системы увеличивается с течением времени
После использования systemd-analyze
некоторое количество пользователей заметило, что их время загрузки значительно увеличилось по сравнению с тем, к чему они привыкли. После использования systemd-analyze blame
NetworkManager тратил необычно большое количество времени на запуск.
Проблема некоторых пользователей была связана с тем, что /var/log/journal
становился слишком большим. При этом также может уменьшаться скорость работы других команд, например, systemctl status
или journalctl
. Для решения проблемы можно удалить все файлы из каталога журнала (в идеале - сделав где-нибудь резервные копии, хотя бы временно) и затем установить предел размера файла журнала, как описано в разделе #Ограничение размера журнала.
Смотрите также
- Официальный веб-сайт (англ.)
- Статья в Википедии
- Страницы справочных руководств (англ.)
- Оптимизации systemd (англ.)
- FAQ (англ.)
- Советы и трюки (англ.)
- systemd для администраторов (PDF) - перевод цикла статей Леннарта Поттеринга (Lennart Poettering)
- О systemd в Fedora Project (англ.)
- Отладка проблем systemd (англ.)
- часть 1 и часть 2 вводной статьи в журнале The H Open (англ.)
- Блог Lennart'а (англ.)
- Status update (англ.)
- Status update2 (англ.)
- Status update3 (англ.)
- Самые последние изменения (англ.)
- Шпаргалка Fedora по переходу с SysVinit на systemd
- Статья systemd в Gentoo Wiki (англ.)