# systemd (Русский)

Ссылки по теме

- systemd/Пользователь
- systemd/Службы
- systemd/Функциональность cron
- systemd FAQ
- Init Rosetta (Русский)
- Список демонов
- Udev (Русский)
- Ускорение загрузки системы
- Позволить пользователям выключать машину

Цитата с веб-страницы проекта:

  systemd - менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации, использует сокеты и активацию D-Bus для запускаемых служб, предлагает запуск демонов по необходимости, отслеживает процессы при помощи контрольных групп Linux, поддерживает мгновенные снимки и восстановление состояния системы, монтирование и точки монтирования, а также внедряет основанную на зависимостях логику контроля процессов сложных транзакций.

Обратите внимание: За детальным объяснением причин происходящего перехода Arch'а на systemd обратитесь к сообщению на англоязычном форуме

## Основы использования systemctl

Главная команда для отслеживания и контроля состояния systemd - команда systemctl. Некоторые из вариантов ее использования связаны с изучением состояния системы и управлением системой и службами. Обратитесь к странце руководства `man 1 systemctl` для получения более детальной информации.

Совет: Вы можете использовать все приведенные ниже команды systemctl с ключом `-H пользователь@хост` для того, чтобы контролировать systemd на удаленной машине. В этом случае для соединения с удаленным процессом systemd будет использоваться SSH
Обратите внимание: systemadm - официальная графическая оболочка для systemctl. Она доступна в виде пакета systemd-ui-git из AUR

### Анализ состояния системы

Список запущенных юнитов:

    $ 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`.

Совет: Большинство указанных ниже команд также работают, если указать несколько юнитов. Для получения дополнительной информации смотрите страницу справочного руководства `man systemctl`

Незамедлительно запустить юнит:

    # 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

## Написание пользовательских файлов .service

Синтаксис файлов юнитов systemd вдохновлен файлами .desktop XDG Desktop Entry Specification, а они, в свою очередь - файлами .ini Microsoft Windows.

Для просмотра большего количества примеров смотрите статью systemd/Службы.

### Обработка зависимостей

В случае использования systemd зависимости могут быть указаны правильным построением файлов юнитов. Наиболее частый случай -- юниту A требуется, чтобы юнит B был запущен перед тем, как запустится сам юнит A. В этом случае добавьте строки `Requires=B` и `After=B` в секцию `[Unit]` файла службы A. Если подобная зависимость не является обязательной, взамен указанных выше добавьте, соответственно, строки `Wants=B` и `After=B`. Обратите внимание, что `Wants=` и `Requires=` не подразумевают `After=`, что означает, что если `After=` не определено, два юнита будут запущены параллельно друг другу.

Обычно зависимости указываются в файлах служб, а не в целевых юнитах. Например, network.target потребуется любой службе, которая связана с настройкой ваших сетевых интерфейсов, поэтому в любом случае определите загрузку вашего пользовательского юнита после запуска network.target.

### Тип

Существует несколько различных типов запуска служб, которые надо иметь в виду при написании пользовательского файла службы. Тип определяется параметром `Type=` в секции `[Service]`. Обратитесь к руководству `man systemd.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

### Редактирование предоставленных пакетами файлов юнитов

Для того, чтобы отредактировать предоставляемый пакетом файл юнита, вы можете создать каталог с названием `/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-delta, чтобы увидеть, какие файлы юнитов были переопределены и что конкретно было изменено

### Подсветка синтаксиса файлов юнитов в Vim

Подсветку синтаксиса для файлов юнитов systemd в редакторе Vim можно включить, установив пакет vim-systemd из официальных репозиториев.

## Цели

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). Для изменения цели загрузки по умолчанию добавьте один из следующих параметров ядра в ваш загрузчик:

Совет: Расширение .target можно опустить

- `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)`.

Обратите внимание: Этот способ может не сработать для установки опций в `/sys`, поскольку служба systemd-tmpfiles-setup может запускаться перед тем, как будут загружены соответствующие модули устройств. В этом случае при помощи команды `modinfo модуль` вы можете проверить, имеет ли модуль параметр для установки необходимой вам опции, и установить эту опцию в конфигурационном файле /etc/modprobe.d. В противном случае для установки верных атрибутов сразу, как только устройство появляется, вам придется написать правило udev

## Таймеры

Таймер - это файл конфигурации юнита, имя которого заканчивается на ".timer". Он расшифровывает информацию о таймере, контролируемом при помощи systemd, для активации в определенное время. Чтобы увидеть список всех активных таймеров, используйте следующую команду:

    $ systemctl list-timers

Обратите внимание: Таймеры способны в значительной степени заменить функциональность cron. Для получения дополнительной информации, пожалуйста, обратитесь к статье systemd/функциональность cron

## Журнал

systemd имеет собственную систему ведения логов, названную журналом (journal). В связи с этим больше не требуется запускать демон syslog. Для чтения логов используйте команду:

    # journalctl

В Arch Linux каталог `/var/log/journal/` является частью пакета systemd, и по умолчанию (когда в конфигурационном файле `/etc/systemd/journald.conf` параметр `Storage=` имеет значение `auto`) журнал записывается именно в него. В случае, если вы или какая-либо программа удалили его, systemd не воссоздаст ее автоматически , но при следующем обновлении systemd эта директория будет восстановлена. До восстановления данной директории логи будут записываться в каталог `/run/systemd/journal`. Это означает, что логи будут потеряны при перезагрузке.

Совет: Если каталог `/var/log/journal/` расположен в файловой системе btrfs, вам следует отключить копирование при записи (Copy-on-Write) для этого каталога. Для получения дополнительной информации смотрите основную статью: Btrfs#Copy-On-Write (CoW)

### Фильтрация вывода

journalctl позволяет фильтровать вывод по особым полям. Помните, что, если должно быть отражено большое количество сообщений или необходима фильтрация в большом промежутке времени, вывод этой команды может быть отложен на какое-то время.

Примеры:

- Показать все сообщения с момента текущей загрузки системы:

      # journalctl -b

  Однако, пользователи часто интересуются сообщениями не для текущей, а для предыдущей загрузки (например, если произошел невосстановимый сбой системы). Это возможно, если задать параметр флагу `-b`: `journalctl -b -0` покажет сообщения с момента текущей загрузки, `journalctl -b -1` - предыдущей загрузки, `journalctl -b -2` - следующей за предыдущей, и т.д. Для просмотра полного описания смотрите страницу справочного руководства `man 1 journalctl`: имеется гораздо более мощная семантика
- Показывать новые сообщения:

      # journalctl -f

- Показать все сообщения для конкретного исполняемого файла:

      # journalctl /usr/lib/systemd/systemd

- Показать все сообщения для конкретного процесса:

      # journalctl _PID=1

- Показать все сообщения для конкретного юнита:

      # journalctl -u netcfg

- Показать кольцевой буфер ядра:

      # journalctl _TRANSPORT=kernel

Для получения дополнительной информации смотрите страницы справочного руководства `man 1 journalctl` и `man 7 systemd.journal-fields` или пост в блоге Lennert'а.

Совет: В некоторых случаях при просмотре логов бывает лучше включить в `journalctl` мягкую упаковку (soft wrap). Вы можете использовать следующую команду для его запуска со включенной мягкой упаковкой: `env SYSTEMD_LESS=FRXMK journalctl`. Если вы хотите установить такое поведение по умолчанию, просто добавьте новую функцию в ваш `~/.bashrc` или `~/.zshrc`:

    journalctl() {
    env SYSTEMD_LESS=FRXMK journalctl "$@"
    }

### Ограничение размера журнала

Если журнал сохраняется при перезагрузке, его размер по умолчанию ограничен значением в 10% от объема соответствующей файловой системы. Например, для директории `/var/log/journal`, расположенной на корневом разделе в 50 Гбайт, максимальный размер журналируемых данных составит 5 Гбайт. Максимальный объем постоянного журнала можно контролировать при помощи значения `SystemMaxUse` в конфигурационном файле `/etc/systemd/journald.conf`, поэтому для ограничения его объемом, например, в 50 Mбайт раскомментируйте и отредактируйте соответствующую строку:

    SystemMaxUse=50M

Для получения дополнительной информации обратитесь к странице справочного руководства `man journald.conf`.

### Journald в связке с классическим демоном syslog

Совместимость с классической реализацией syslog обеспечивается сокетом `/run/systemd/journal/syslog`, в который перенаправляются все сообщения. Чтобы дать возможность демону syslog работать вместе с журналом systemd, следует привязать данный демон к указанному сокету вместо `/dev/log` (официальное сообщение). Пакетом syslog-ng из репозиториев автоматически предоставляется необходимая конфигурация.

    # systemctl enable syslog-ng

Хорошее руководство по journalctl находится здесь (англ.)

### Отправка вывода 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

Tip:

- Если вы дополните хуком `timestamp` ваш массивr `HOOKS` в конфигурационном файле `/etc/mkinitcpio.conf` и пересоберете ваш образ initramfs командой `mkinitcpio -p linux`, systemd-analyze сколько времени затрачивается на initramfs.

- Если вы загружаетесь при помощи UEFI и используете загрузчик, в который имплементирова Boot Loader Interface от systemd (что в настоящий момент применено только в Gummiboot ), systemd-analyze дополнительно сможет показать, сколько времени затрачено на прошивку EFI сам загрузчик.

Чтобы увидеть список запускаемых файлов юнитов, отсортированный по потраченному каждым из них на загрузку времени, выполните команду:

    $ 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-git из AUR, поставляемым с недокументированным сервисом systemd. После установки bootchart2 выполните команду:

    # systemctl enable bootchart

Обратитесь к документации bootchart (англ.) за дальнейшей и детализированной информацией об использовании данной версии bootchart.

### Readahead

systemd поставляется со свой реализации технологии readahead, что в принципе должно усовершенствовать процесс загрузки системы. Однако, в зависимости от версии вашего ядра и типа жесткого диска, скорость обращения к данным может разниться (например, может быть медленнее). Чтобы включить данный сервис, выполните:

    # systemctl enable systemd-readahead-collect systemd-readahead-replay

Не забудьте, что волшебство технологии readahead подействует только после нескольких перезапусков системы

## Решение проблем

### Изучение ошибок 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 ожидает некоторое время, пока каждая служба завершит свою работу самостоятельно, и только потом пытается принудительно завершить (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.

### Отключение журналирования аварийных дампов памяти приложений

Выполните следующее, чтобы перезаписать настройки в `/lib/sysctl.d/`:

    # ln -s /dev/null /etc/sysctl.d/50-coredump.conf
    # sysctl kernel.core_pattern=core

Это отключит журналирование дампов памяти.

Обратите внимание, что значение по умолчанию RLIMIT_CORE (0) означает, что не будут записываться никакие основные файлы. Если они вам нужны, вам потребуется также "снять ограничение" на размер основных файлов в оболочке:

    $ ulimit -c unlimited

Для получения дополнительной информации смотрите страницу sysctl.d и документацию по /proc/sys/kernel.

### Сообщение об ошибке при перезагрузке или выключении

#### 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` становился слишком большим. Таким образом, для решения проблемы можно удалить все файлы из этого каталога (в идеале - сделав где-нибудь резервные копии, хотя бы временно) и затем установить предел размера файла журнала, как описано в разделе #Ограничение размера журнала.

## Смотрите также

- Официальный веб-сайт (англ.)
- Статья в Википедии
- Страницы справочных руководств (англ.)
- Оптимизации 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 (англ.)

Categories:

- Daemons and system services (Русский)
- Boot process (Русский)
- Русский