Systemd coredump что это
Перейти к содержимому

Systemd coredump что это

  • автор:

Core dump (Русский)

Состояние перевода: На этой странице представлен перевод статьи Core dump. Дата последней синхронизации: 15 февраля 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Дамп памяти (core dump) — это файл, в который записывается адресное пространство (память) процесса при его нештатном завершении. Дампы ядра могут создаваться по требованию (например, отладчиком) или автоматически при завершении процесса. Дампы памяти создаются ядром при сбое программы и могут быть переданы вспомогательной программе (например, systemd-coredump(8) ) для дальнейшей обработки. Дамп памяти обычно не используется обычным пользователем, но может быть передан разработчикам по их запросу, которым будет очень полезно иметь снимок состояния программы на момент сбоя, особенно если сбой трудно воспроизвести.

Отключение автоматических дампов памяти

Пользователи могут захотеть отключить автоматические дампы памяти по нескольким причинам:

  • Производительность: создание дампа для процессов, занимающих много памяти, может привести к трате системных ресурсов и задержке очистки памяти.
  • Дисковое пространство: дампы процессов, занимающих много памяти, могут занимать место на диске, равное, а то и большее, чем объём памяти процесса, если их не сжимать.
  • Безопасность: хотя дампы обычно может читать только root, они могут содержать конфиденциальные данные (например, пароли или криптографические ключи), которые записываются на диск после сбоя.

Используя sysctl

Можно использовать sysctl, чтобы изменить kernel.core_pattern для отключения дампов. Создайте файл:

/etc/sysctl.d/50-coredump.conf
kernel.core_pattern=/dev/null

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

# sysctl -p /etc/sysctl.d/50-coredump.conf

Используя systemd

Поведение systemd по умолчанию определено в файле /usr/lib/sysctl.d/50-coredump.conf , который прописывает kernel.core_pattern для вызова systemd-coredump . Он сохраняет дампы ядра для всех процессов в /var/lib/systemd/coredump . Поведение systemd-coredump можно переопределить, создав в /etc/systemd/coredump.conf.d/ файл ( coredump.conf(5) § DESCRIPTION ,, [1]):

/etc/systemd/coredump.conf.d/custom.conf
[Coredump] Storage=none

Примечание: Не забудьте прописать имя секции [Coredump] , иначе опция будет проигнорирована.

Затем перезагрузите настройки systemd.

Одного этого метода обычно достаточно для отключения записи дампов, если в системе нет других программ, включающих автоматические дампы, но дамп памяти всё равно генерируется в памяти и systemd-coredump всё равно запускается.

Используя PAM limits

Максимальный размер дампа памяти для пользователей, вошедших в систему через PAM, задаётся в файле limits.conf. Установка нулевого значения полностью отключает дампы памяти. [2]

/etc/security/limits.conf
* hard core 0

Используя ulimit

Командные оболочки вроде bash и zsh имеют встроенную команду ulimit, которую можно использовать для просмотра или изменения ограничений на ресурсы оболочки и запускаемых ею процессов. Подробнее смотрите bash(1) § SHELL BUILTIN COMMANDS или zshbuiltins(1) .

Отключение дампов памяти в текущей командной оболочке:

$ ulimit -c 0

Создание дампа памяти

Чтобы сгенерировать дамп памяти произвольного процесса, сначала установите пакет gdb . Затем найдите PID запущенного процесса, например, с помощью pgrep:

$ pgrep -f firefox
2071 firefox

Подключитесь отладчиком к этому процессу:

$ gdb -p 2071

И затем в отладчике выполните:

(gdb) generate-core-file Saved corefile core.2071 (gdb) quit

Теперь у вас есть дамп памяти в файле core.2071 .

Куда они попадают?

sysctl kernel.core_pattern определяет, куда отправляются автоматические дампы памяти. По умолчанию их принимает systemd-coredump, который настраивается через файл /etc/systemd/coredump.conf . По умолчанию он записывает дампы в /var/lib/systemd/coredump (опция Storage=external ), сжимая их с помощью zstd (опция Compress=yes ). Кроме того, можно настроить различные ограничения на размер хранилища.

Примечание: Значение по умолчанию для kernel.core_pattern задаётся в файле /usr/lib/sysctl.d/50-coredump.conf . Этот файл может быть замаскирован или переопределён для использования другого значения в соответствии с обычными правилами sysctl.d(5) .

Чтобы получить дамп памяти из журнала, смотрите coredumpctl(1) .

Изучение дампа памяти

Команда coredumpctl покажет список сохранённых дампов, среди которых можно найти нужный:

# coredumpctl list

Для поиска нужного дампа можно использовать PID, имя исполняемого файла, путь к исполняемому файлу или предикат journalctl (подробнее: coredumpctl(1) и journalctl(1) ). Просмотр подробностей о дампах ядра:

# coredumpctl info соответствие 

Обратите внимание на строку «Signal», она поможет определить причину сбоя. Для более глубокого анализа вы можете изучить backtrace с помощью gdb:

# coredumpctl gdb соответствие 

После запуска gdb можно использовать команду bt для получения backtrace:

(gdb) bt

Если отладочные символы нужны, но не найдены, можно попробовать получить их, как описано в статье Отладка/Трассировка.

Удаление дампов памяти

Файлы дампов памяти, хранящиеся в /var/lib/systemd/coredump/ , будут автоматически очищаться командой systemd-tmpfiles —clean , которая запускается ежедневно с помощью systemd-tmpfiles-clean.timer . Дампы памяти настроены на хранение не менее 3 дней, смотрите systemd-tmpfiles —cat-config .

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

  • american fuzzy lop — Инструмент для автоматизированного тестирования ядра и программ
  • Filesystem fuzzing — Статья LWN о тестировании файловых систем на наличие ошибок

Retrieved from «https://wiki.archlinux.org/index.php?title=Core_dump_(Русский)&oldid=775028»

  • Development (Русский)
  • Security (Русский)

Linux: создание coredump памяти процесса, systemd-coredump и Debian

Возникла необходимость получить дамп РНР-процесса на Debian 9.

Рассмотрим механизм ядра, позволящий создать дамп, и настройку создания дампов в Linux.

Ниже будем говорить о создании дампа памяти процесса в Linux, а не дампа ядра при kernel panic – там он иной, см. Kdump на Arch Wiki.

Linux Core Dump

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

Для этого при выполнении такой операции ядро отправляет один из аварийных сигналов процессу, после чего процесс обрабатывает сигнал сам, или с помощью сторонних обработчиков, что запускает механизм ядра, который создаёт дамп.

Список таких сигналов задаётся в макросе SIG_KERNEL_COREDUMP_MASK :

. #define SIG_KERNEL_COREDUMP_MASK (\ rt_sigmask(SIGQUIT) | rt_sigmask(SIGILL) | \ rt_sigmask(SIGTRAP) | rt_sigmask(SIGABRT) | \ rt_sigmask(SIGFPE) | rt_sigmask(SIGSEGV) | \ rt_sigmask(SIGBUS) | rt_sigmask(SIGSYS) | \ rt_sigmask(SIGXCPU) | rt_sigmask(SIGXFSZ) | \ SIGEMT_MASK .

Который используется в другом макросе – sig_kernel_coredump :

. #define sig_kernel_coredump(sig) siginmask(sig, SIG_KERNEL_COREDUMP_MASK) .

Который срабывает в случае Fatal-ошибок, и вызывает do_coredump() :

. fatal: . if (sig_kernel_coredump(signr)) < if (print_fatal_signals) print_fatal_signal(ksig->info.si_signo); proc_coredump_connector(current); . do_coredump(&ksig->info); > .

Ну а сама do_coredump() создаёт дамп.

Сигналы и создание дампа

Проверим работу дампа.

Берём простой код на Си:

#include #include int main() < while(1) < pid_t pid = getpid(); printf ("Working with PID %lu\n", pid); sleep(5); >>

Собираем, и запускаем:

$ gcc make_dump.c -o make_dump $ ./make_dump Working with PID 2714790

Во второй консоли – отправляем один из сигналов, например SIGSEGV (Segmentation violation), код 11:

$ kill -s SIGSEGV 2714790

В окне с приложением проверяем:

$ ./make_dump Working with PID 2714790 . Working with PID 2714790 Segmentation fault (core dumped)

Проверяем файл дампа:

$ ls -l /tmp/ | grep 2714790 -rw------- 1 setevoy setevoy 380928 Mar 10 11:24 coredump-make_dump.2714790

Аналогично можно создать дамп практически любого процесса, например – запустим sleep :

$ sleep 100 & [1] 2761144 $ kill -s SIGSEGV 2761144 [1]+ Segmentation fault (core dumped) sleep 100 $ file /tmp/coredump-sleep.2761144 /tmp/coredump-sleep.2761144: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 'sleep 100', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/sleep', platform: 'x86_64'
GDB – создать core dump

Кроме отправки сигнала – с помощью gdb , а именно gcore , можно создать дамп работающего процесса:

$ sleep 100 & [1] 2762961 $ sudo gcore 2762961 . Saved corefile core.2762961 $ file core.2762961 core.2762961: ELF 64-bit LSB core file
GDB – прочитать core dump

Что бы просмотреть содержимое – можем использовать gdb , которому передаём путь к исполняемому файлу, процесс которого сгенерировал дамп, и путь к самому файлу дампа:

$ gdb make_dump coredump-make_dump.2714790 . [New LWP 2714790] Core was generated by `./make_dump'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f50d566e27e in clock_nanosleep@GLIBC_2.2.5 () from /usr/lib/libc.so.6 (gdb)
kernel.core_pattern

Во время создания дампа – ядро проверяет параметр kernel.core_pattern , который определяет то, как будет обработан дамп.

Тут можно задать путь и имя файла, в который будет записан дамп, либо передать создание дампа внешнему обработчику, например systemd-coredump (рассмотрим ниже).

См. документацию Naming of core dump files тут>>>.

Из наиболее используемых опций тут:

  • %e executable filename (without path prefix)
  • %p PID of dumped process, as seen in the PID namespace in which the process resides
  • %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)

Собственно файл /tmp/coredump-make_dump.2714790, который мы открыли в GDB, и состоит из kernel.core_pattern = /tmp/coredump-%e.%p :

  1. /tmp каталог
  2. %e – имя файла начинается с coredump + имя исполняемого файла make_dump
  3. %p – и PID убитого процесса – 2714790

Помимо указания на путь к файлу и созданию его имени – в core_pattern можно указать пайп | , и передать данные через него, например в /dev/null или в хендлер типа systemd-coredump .

limits.conf

Кроме имени файла – ядро проверит значение soft и hard лимитов для core в /etc/security/limits.conf :

$ cat /etc/security/limits.conf | grep core # - core - limits the core file size (KB) #* soft core 0

Либо проверяем в рабочем окружении:

$ ulimit -c unlimited

Лимиты конкретного процесса можно получить через его дескриптор в /proc :

$ ./make_dump Working with PID 2753034
$ cat /proc/2753034/limits Limit Soft Limit Hard Limit Units . Max core file size unlimited unlimited bytes .
fs.suid_dumpable

Иногда дамп может не создаваться, если процесс в процессе выполнения выполнил запрос на смену UID, например через вызов setuid() .

Определяется флагом fs.suid_dumpable :

$ sysctl fs.suid_dumpable fs.suid_dumpable = 2

Может принимать значение 0, 1 или 2, см. man proc:

  • 0: (default) This provides the traditional (pre-Linux 2.6.13) behaviour. A core dump will NOT be produced for a process which has changed credentials (by calling seteuid or similar) or whose binary does not have read permission enabled.
  • 1: (“debug“) All processes dump core when possible.
  • 2: (“suidsafe“) Any binary which normally would not be dumped (see “0” above) is dumped readable by root only.

systemd-coredump

В systemd , разумеется, добавлен свой обработчик дампов – уже упомянутый systemd-coredump .

На Arch Linux он используется по-умолчанию, на Debian 9 ставим из репозитория:

$ sudo apt -y install systemd-coredump

Файл параметров – /etc/systemd/coredump.conf .

После установки настраиваем ядро – через пайп передаём создание дампа в systemd-coredump :

root@bttrm-production-app-1:/home/admin# echo '|/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %e' > /proc/sys/kernel/core_pattern
root@bttrm-production-app-1:/home/admin# cat /proc/sys/kernel/core_pattern |/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %e

Создаём дамп какого-то процесса:

root@bttrm-production-app-1:/home/admin# sleep 10 & [1] 27117 root@bttrm-production-app-1:/home/admin# kill -s 11 27117 [1]+ Segmentation fault (core dumped) sleep 10
coredumpctl

Для работы с дампами через systemd-coredump – используем coredumpctl :

root@bttrm-production-app-1:/home/admin# coredumpctl TIME PID UID GID SIG COREFILE EXE Mon 2020-03-09 20:10:16 EET 20882 0 0 11 present /home/admin/dump_test . Tue 2020-03-10 09:04:14 EET 16786 1003 1003 11 present /usr/sbin/php-fpm7.4 Tue 2020-03-10 12:23:43 EET 27117 0 0 11 present /bin/sleep

В колонке SIG сразу видим код сигнала, с которым был убит процесс, в данном случае 11 == SIGSEGV .

Сами файлы дампов systemd-coredump сохраняет в /var/lib/systemd/coredump :

root@bttrm-production-app-1:/home/admin# ll /var/lib/systemd/coredump/ total 125376 -rw-r----- 1 root root 25208 Mar 9 20:10 core.dump_test.0.6bb23c691d354e9dbf4382d109a5c1d4.20882.1583777416000000000000.lz4 . -rw-r----- 1 root root 33962 Mar 10 12:23 core.sleep.0.6bb23c691d354e9dbf4382d109a5c1d4.27117.1583835823000000000000.lz4

Просмотреть дамп – передаём условие для MATCH, например – PID:

root@bttrm-production-app-1:/home/admin# coredumpctl info 27117 PID: 27117 (sleep) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Tue 2020-03-10 12:23:43 EET (3min 3s ago) Command Line: sleep 10 Executable: /bin/sleep . Hostname: bttrm-production-app-1 Storage: /var/lib/systemd/coredump/core.sleep.0.6bb23c691d354e9dbf4382d109a5c1d4.27117.1583835823000000000000.lz4 Message: Process 27117 (sleep) of user 0 dumped core. Stack trace of thread 27117: #0 0x00007fc1a8053270 __nanosleep (libc.so.6) #1 0x000056159fa6f91f n/a (sleep) #2 0x000056159fa6f700 n/a (sleep) #3 0x000056159fa6c9a4 n/a (sleep) #4 0x00007fc1a7fbb2e1 __libc_start_main (libc.so.6) #5 0x000056159fa6ca7a n/a (sleep)

Debian – core dump не создаётся

Всё вышеописанное отлично работает на двух нотбуках с Arch Linux – но на серверах проекта с Debian 9 дамп обычным способом, без systemd-coredump , не создаётся.

root@bttrm-production-app-1:/home/admin# cat /proc/sys/kernel/core_pattern /tmp/core-%e.%p

Запускаем процесс, убиваем – файл дампа в /tmp не появляется.

Запускаем приложение ещё раз:

root@bttrm-production-app-1:/home/admin# ./dump_test Working with PID 27954

И проверяем лимиты процесса

root@bttrm-production-app-1:/home/admin# cat /proc/27954/limits Limit Soft Limit Hard Limit Units . Max core file size 0 unlimited bytes .

Soft лимит размера файла дампа задан в ноль, т.е. создание дампа отключено вообще.

Задаём его в unlimited:

root@bttrm-production-app-1:/home/admin# ulimit -S -c unlimited

Запускаем программу, проверяем лимит теперь:

root@bttrm-production-app-1:/home/admin# ./dump_test 1>/dev/null & [3] 28399 root@bttrm-production-app-1:/home/admin# cat /proc/$!/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes .
root@bttrm-production-app-1:/home/admin# sleep 10 & [4] 28613 root@bttrm-production-app-1:/home/admin# kill -s 11 $!

И проверяем его:

root@bttrm-production-app-1:/home/admin# ls -l /tmp/coredump-sleep.28613 -rw------- 1 root root 380928 Mar 10 12:47 /tmp/coredump-sleep.28613

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

  • Understand and configure core dumps on Linux
  • Hunting the Core
  • Core dump (Arch Wiki)
  • Generate PHP core dumps on segfaults in PHP-FPM
  • Generating a gdb backtrace
  • Проблема с eaccelerator и генерация coredump для php-fpm
  • How to get a core dump for a segfault on Linux
  • kill: Creating a core dump

Пакет: systemd-coredump (254.5-1)

This package provides systemd tools for storing and retrieving coredumps:

* systemd-coredump * coredumpctl

Другие пакеты, относящиеся к systemd-coredump

  • зависимости
  • рекомендации
  • предложения
  • enhances
  • dep: libc6 (>= 2.34) [не alpha, ia64, sh4] библиотека GNU C: динамически подключаемые библиотеки
    также виртуальный пакет, предоставляемый libc6-udeb dep: libc6 (>= 2.37) [sh4]
  • dep: libc6.1 (>= 2.34) [alpha] библиотека GNU C: динамически подключаемые библиотеки
    также виртуальный пакет, предоставляемый libc6.1-udeb dep: libc6.1 (>= 2.37) [ia64]
  • dep: liblz4-1 (>= 0.0~r130) библиотека быстрого алгоритма сжатия LZ — динамическая версия
  • dep: liblzma5 (>= 5.1.1alpha+20120614) библиотека для работы с архивами в формате XZ
  • dep: libsystemd-shared (= 254.5-1) systemd shared private library
  • dep: libzstd1 (>= 1.5.5) быстрый алгоритм сжатия без потерь
  • dep: systemd загрузчик системы и служб
  • rec: libdw1 извлечение отладочной информации DWARF из программ

Загрузка systemd-coredump

Загрузить для всех доступных архитектур

Архитектура Размер пакета В установленном виде Файлы
alpha (неофициальный перенос) 95,4 Кб 371,0 Кб [список файлов]
amd64 97,9 Кб 261,0 Кб [список файлов]
arm64 93,5 Кб 369,0 Кб [список файлов]
armel 95,2 Кб 239,0 Кб [список файлов]
armhf 95,3 Кб 211,0 Кб [список файлов]
hppa (неофициальный перенос) 100,0 Кб 273,0 Кб [список файлов]
i386 99,2 Кб 259,0 Кб [список файлов]
ia64 (неофициальный перенос) 106,2 Кб 338,0 Кб [список файлов]
m68k (неофициальный перенос) 94,9 Кб 247,0 Кб [список файлов]
mips64el 90,9 Кб 245,0 Кб [список файлов]
ppc64 (неофициальный перенос) 97,8 Кб 369,0 Кб [список файлов]
ppc64el 98,1 Кб 369,0 Кб [список файлов]
riscv64 96,6 Кб 236,0 Кб [список файлов]
s390x 95,0 Кб 253,0 Кб [список файлов]
sh4 (неофициальный перенос) 103,2 Кб 241,0 Кб [список файлов]
sparc64 (неофициальный перенос) 91,8 Кб 2 173,0 Кб [список файлов]
x32 (неофициальный перенос) 97,7 Кб 239,0 Кб [список файлов]

Эта страница также доступна на следующих языках (Как установить язык по умолчанию):

Чтобы сообщить о проблеме, связанной с веб-сайтом, отправьте сообщение (на английском) в список рассылки debian-www@lists.debian.org. Прочую контактную информацию см. на странице Debian Как с нами связаться.

Авторские права © 1997 — 2023 SPI Inc.; См. условия лицензии. Debian это торговый знак компании SPI Inc. Об этом сайте.

systemd 215

4 июля был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала и управления сессиями пользователей. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые задачи по управлению системой — от настройки подсистемы VT (systemd-vconsole-setup) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Большая часть изменений, вошедших в этот релиз, была направлена на поддержку т. н. stateless-систем, в которых все данные находятся на разделе /usr (монтируемом в режиме только для чтения), а корень (включая /etc) размещается на tmpfs и автоматически пересоздаётся при каждой загрузке системы. Этот функционал предполагается использовать в легковесных контейнерах, а также как средство «полного сброса» без переустановки ОС.

Изменения по поддержке stateless-систем:

  • Добавлен компонентsystemd-sysusers, способный автоматически добавлять и исправлять записи о служебных пользователях в /etc/passwd и /etc/group , основываясь на декларативных определениях из /usr/lib/sysusers.d . Наиболее важные определения уже поставляются в этом релизе.
    Этот функционал является частью работы по поддержке stateless-систем.
  • В секции [Unit] юнит-файлов добавлена директива ConditionNeedsUpdate= , инструктирующая systemd запускать юнит-файл только в том случае, если требуется обновление или перестроение директорий /etc или /var. Юнит-файлы, использующие эту директиву, вероятно, должны содержать также директиву Before=systemd-update-done.service . В поставку включён ряд unit-файлов, использующих этот функционал и реализующих перестроение:
    • базы данных аппаратного обеспечения udev ( /etc/udev/hwdb.bin );
    • каталога сообщений journald ( /var/lib/systemd/catalog/database );
    • кэша динамического компоновщика ( /etc/ld.so.cache , т. е. ldconfig).

    Прочие изменения:

    • systemd-networkd теперь включает в себя клиент DHCPv6, поддержку IPv6 Router Solicitation, а также сервер DHCPv4.
      Клиент DHCPv4 теперь поддерживает получение от сервера статических маршрутов.
      Секция DHCPv4 network-файлов была переименована в DHCP ; совместимость со старым синтаксисом сохранена.
    • systemd-networkd теперь поддерживает управление виртуальными сетями VXLAN, TUN/TAP и dummy-интерфейсами.
    • systemd-networkd теперь поддерживает автоматическое назначение интерфейсам статических адресов из предварительно указанного диапазона. Этот функционал предназначен для управления большим числом однотипных соединений, таких, как veth-интерфейсы между хостом и контейнерами.
    • systemd-coredump теперь генерирует стектрейс всех потоков упавшей программы и пишет его в лог. Этот функционал реализован на библиотеке libdw из состава elf-utils.
    • systemd-coredump теперь может сохранять core-дампы на диск ( /var/lib/systemd/coredump ), а не в лог. По умолчанию включен режим сохранения на диск.
      Также был добавлен конфигурационный файл /etc/systemd/coredump.conf , позволяющий настраивать это поведение и некоторые другие параметры.
    • Утилита systemd-coredumpctl была переименована в coredumpctl, что означает её готовность к широкому использованию.
      Также была добавлена команда coredumpctl info , отображающая подробную информацию о зарегистрированных core-дампах.
    • journald теперь по умолчанию работает в режиме SplitMode=uid , т. е. файлы логов разделяются по UID источников сообщений.
    • Добавлена команда systemd is-system-running , позволяющая узнать общий статус запуска системы (starting, stopping, running, maintenance, degraded).
    • machined теперь экспортирует (позволяет узнать через D-Bus) версию ОС в запущенных контейнерах.
    • Команда systemctl -H (подключение к другой машине по сети) теперь позволяет заходить в контейнеры, запущенные на такой машине. Синтаксис для этого выглядит как root@host:container . Следует обратить внимание, что пользователь должен быть root, т. к. обращение к контейнеру — привилегированная операция.
    • В секции [Mount] unit-файлов добавлена директива SloppyOptions= , эквивалентная ключу -s программы mount(8). Эта директива включает режим нестрогой обработки несуществующих опций монтирования.
    • В секции [Install] юнит-файлов добавлена директива DefaultInstance= , указывающая, какую строку использовать как instance по умолчанию, если запрошено включение шаблонного юнита без явного указания instance.
    • В секции [Service] юнит-файлов добавлена директива RestartForceExitStatus= , позволяющая указать набор кодов возврата из главного процесса, при которых служба будет принудительно перезапущена (вне зависимости от значения директивы Restart= ).
    • Добавлена обработка параметров ядра systemd.wants= , systemd.mask= и systemd.debug-shell . Их обработка реализована в новом генераторе systemd-debug-generator.
    • Добавлена пассивная цель cryptsetup-pre.target . Она предназначена для служб, которые должны запуститься до начала инициализации LUKS-устройств.
    • Добавлена страница документации file-hierarchy(7), содержащая рекомендации по организации иерархии файловой системы в дистрибутивах, использующих systemd. По сути, это является обновлённой версией FHS или hier(7). (Уже обсудили на ЛОРе.)
      Также была добавлена утилита systemd-path , позволяющая узнать точные (действующие) пути для некоторых пунктов из указанной документации.
    • Из поставки исключён unit-файл, периодически (по таймеру) пересоздающий кэш man-db. Он теперь будет поставляться в составе самого man-db (начиная со следующего релиза).
    • systemd.pc теперь экспортирует больше путей (в т. ч. libdir и некоторые директории файлов конфигурации второстепенных компонентов systemd).
    • В поставку включены макросы RPM для обработки файлов конфигурации systemd-sysusers, systemd-sysctl и systemd-binfmt (т. е. для их считывания и применения «на лету»).

    Изменения, касающиеся udev:

    • Файлы устройств /dev/loop-control и /dev/btrfs-control теперь принадлежат служебной группе disk .
    • Функционал предсказуемых имён сетевых интерфейсов в udev теперь использует свойство dev_port (добавленное в Linux 3.15) вместо dev_id, чтобы различать несколько PCI-портов на одной PCI-функции.
    • Добавлена новая служебная группа input , которая теперь назначается всем файлам устройств ввода. Её предназначение во многом аналогично таковому для групп audio и video .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *