Файл /etc/systemd/system.conf
содержит параметры для управления основными операциями systemd.
Изначально все записи в этом файле закомментированы с указанием
настроек по умолчанию. В этом файле может быть изменен уровень
логирования, а также некоторые базовые настройки ведения файлов
логов. Смотрите страницу руководства systemd-system.conf(5)
для получения подробной информации по каждому параметру.
Обычным поведением systemd является очистка экрана по окончании загрузки. При желании такое поведение можно изменить, выполнив следующую команду:
mkdir -pv /etc/systemd/system/getty@tty1.service.d
cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF
Сообщения, отображаемые при загрузке всегда можно просмотреть,
выполнив команду journalctl
-b
от имени пользователя root
.
По умолчанию каталог /tmp
монтируется
как tmpfs. Если такое поведение нежелательно, его можно
переопределить, выполнив следующую команду:
ln -sfv /dev/null /etc/systemd/system/tmp.mount
В качестве альтернативы, если требуется отдельный раздел для
/tmp
укажите его в /etc/fstab
.
Не создавайте символическую ссылку, указанную выше, если
используется отдельный раздел для /tmp
. Это помешает монтированию корневой
файловой системы (/) в режиме r/w и сделает систему непригодной
для загрузки.
Существует несколько служб, которые создают или удаляют файлы или каталоги:
systemd-tmpfiles-clean.service
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-setup.service
Системные файлы конфигурации расположены в /usr/lib/tmpfiles.d/*.conf
. Локальные
конфигурационные файлы находятся в /etc/tmpfiles.d
. Файлы в /etc/tmpfiles.d
переопределяют файлы с таким же
именем в /usr/lib/tmpfiles.d
.
Смотрите подробности по формату файла в руководстве tmpfiles.d(5).
Обратите внимание, что синтаксис файлов в /usr/lib/tmpfiles.d/*.conf
может сбивать с толку.
Например, по умолчанию, удаление файлов в каталоге /tmp находится в
файле /usr/lib/tmpfiles.d/tmp.conf
в
строке:
q /tmp 1777 root root 10d
q, в поле type, указывает что необходимо создать подраздел с квотами, что применимо только к файловым системам btrfs. Он ссылается на type v который, в свою очередь, ссылается на type d (каталог). Затем создается указанный каталог, если он отсутствует, и настраиваются разрешения и владелец. Содержимое каталога будет очищаться через указанный интервал времени, если указан аргумент age.
Если параметры по умолчанию не нужны, файл следует скопировать в
/etc/tmpfiles.d
и отредактировать по
желанию. Например:
mkdir -p /etc/tmpfiles.d cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d
Параметры юнита можно переопределить, создав каталог и файл
конфигурации в /etc/systemd/system
.
Пример для условного юнита foobar:
mkdir -pv /etc/systemd/system/foobar.service.d
cat > /etc/systemd/system/foobar.service.d/foobar.conf << EOF
[Service]
Restart=always
RestartSec=30
EOF
Дополнительную информацию смотрите на странице руководства
systemd.unit(5).
После создания файла конфигурации запустите systemctl daemon-reload
и
systemctl restart
foobar
, чтобы активировать изменения в службе.
Вместо простых сценариев оболочки, используемых в системах инициализации SysVinit или BSD, systemd использует унифицированный формат для различных типов запускаемых файлов (или юнитов). Команда systemctl используется для запуска, остановки, управления состоянием и получения статуса юнит-файлов. Ниже несколько примеров часто используемых команд:
systemctl list-units -t
<service>
[--all]: выводит список загруженных
юнит-файлов типа service.
systemctl list-units -t
<target>
[--all]: выводит список загруженных
юнит-файлов типа target.
systemctl show -p Wants
<multi-user.target>
:
показывает все юнит-файлы, зависящие от multi-user target
(многопользовательского режима). Target - специальные
юнит-файлы, которые аналогичны уровням запуска в SysVinit.
systemctl status <servicename.service>
:
показывает статус службы servicename. Расширение .service
можно опустить, если нет других юнит-файлов с таким же
именем, например, .socket (которые создают прослушивающий
сокет, обеспечивающий функции аналогичные inetd/xinetd).
Вход в систему, загруженную с помощью systemd, обрабатывается с помощью systemd-journald (по умолчанию), а не классическим демоном системного журнала unix. При желании, вы можете добавить обычный демон системного журнала и заставить их работать бок о бок. Программа systemd-journald сохраняет записи журнала в двоичном формате, а не в обычном текстовом. Для разбора лога предоставляется команда journalctl. Ниже несколько примеров часто используемых команд:
journalctl -r: показывает все содержимое журнала в обратном хронологическом порядке.
journalctl -u UNIT
:
показывает записи журнала, связанные с указанным юнит-файлом.
journalctl -b[=ID] -r: показывает записи журнала с момента последней успешной загрузки (или для идентификатора загрузки) в обратном порядке хронологический порядке.
journalctl -f: предоставляет функциональность, аналогичную tail -f (режим следования).
Дампы ядра полезны для отладки аварийно завершившихся программ,
особенно, когда происходит сбой процесса демона. В системах с
systemd дампы ядра обрабатывается командой systemd-coredump. Команда запишет
дамп в журнал и сохранит сам дамп ядра в /var/lib/systemd/coredump
. Чтобы получить и
обработать дамп, предоставляется инструмент coredumpctl. Несколько примеров
часто используемых команд:
coredumpctl -r: выводит список всех дампов в обратном хронологическом порядке.
coredumpctl -1 info: отображает информацию из последнего дампа ядра.
coredumpctl -1 debug: загружает последний дамп ядра в GDB.
Дампы ядра могут занимать много места на диске. Можно ограничить
место на диске, занимаемое дампами ядра, создав конфигурационный
файл в /etc/systemd/coredump.conf.d
.
Например:
mkdir -pv /etc/systemd/coredump.conf.d
cat > /etc/systemd/coredump.conf.d/maxuse.conf << EOF
[Coredump]
MaxUse=5G
EOF
Смотрите следующие страницы руководства для получения дополнительной информации информация systemd-coredump(8), coredumpctl(1) и coredump.conf.d(5).
Начиная с версии systemd-230, все пользовательские процессы
завершаются, когда завершается пользовательская сессия, даже если
используется nohup или процесс использует функции daemon()
или setsid()
.Это намеренный переход от исторически
разрешительной среды к более ограничительной. Нововведение может
вызвать проблемы, если вы применяете долго работающие программы
(такие как, screen
или tmux), чтобы
оставаться активным после завершения вашей пользовательской сессии.
Есть три способа разрешить процессам работать после того, как сеанс
пользователя завершен.
Включить долгосрочные процессы для
выбранных пользователей: Обычные пользователи
имеют разрешение на включение долгосрочных процессов с
помощью команды loginctl
enable-linger для самих себя. Системные
администраторы могут использовать ту же команду с аргументом
user
для включения
lingering'а пользователю. После этого пользователь может
использовать команду systemd-run, чтобы
запустить длительный процесс. Например: systemd-run --scope --user
/usr/bin/screen. Если вы разрешите выполнение
долгосрочных процессов пользователю, то user@.service
останется даже после завершения всех сеансов входа в систему
и автоматически запустится при загрузке системы. Это является
преимуществом, потому что явно разрешает и запрещает запуск
процессов после завершения сеанса пользователя, но нарушает
обратную совместимость с такими инструментами, как
nohup и
утилитами, которые используют daemon()
.
Включить долгосрочные процессы в
системе(глобально): Вы можете установить
KillUserProcesses=no
в /etc/systemd/logind.conf
для
включения долгосрочных процессов глобально для всех
пользователей. Преимуществом этого метода является то, что вы
оставляете старый метод доступным всем пользователям за счет
явного контроля.
Отключить во время
сборки: вы можете запретить завершение процессов
при сборке systemd, добавив ключ -D
default-kill-user-processes=false
в команде
meson для
systemd. Это полностью отключает возможность systemd убивать
пользовательские процессы в конце сеанса.