Arch linux stop x

How to: Stop X.Org Server

Q. How do I start or stop X.Org from a command prompt?

A. X.org is open-source implementation of the X11 system. It is an open source X11-based desktop infrastructure. Xorg provides an interface between your hardware and the graphical software you want to run. Besides that, Xorg is also fully network-aware, meaning you are able to run an application on one system while viewing it on a different one.

Start X.Org Server

There are two ways, just type startx:
$ startx
Alternatively, run init script such as /etc/init.d/gdm
# /etc/init.d/gdm start
OR
$ sudo /etc/init.d/gdm start

Ctrl+Alt+Backspace – to stop server

Press Ctrl+Alt+Backspace to immediately kill the server – no questions asked.

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

Agian, you can use init script to stop session:
# /etc/init.d/gdm stop
OR
$ sudo /etc/init.d/gdm stop

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Источник

Installation guide (Русский)

Этот документ является руководством по установке Arch Linux с помощью системы, загруженной с официальным установочным образом. Данный образ включает в себя специальные возможности, описанные на странице Install Arch Linux with accessibility options. Также на странице Category:Installation process доступны альтернативные методы установки.

Перед установкой рекомендуется прочитать часто задаваемые вопросы. Чтобы получить разъяснения по понятиям, используемым на этой странице, смотрите статью Help:Чтение. В частности, примеры кода могут содержать заполнители (отформатированные в курсиве ), которые необходимо заменить вручную. Более подробные инструкции приведены в соответствующих статьях ArchWiki и на страницах справочных руководств (man) различных программ. Ссылки и на то, и на другое присутствуют в этом руководстве. Также вы можете получить помощь в IRC-канале и на англоязычном и русскоязычном форумах Arch Linux.

Arch Linux способен работать на любой x86_64-совместимой машине, имеющей хотя бы 512 MiB ОЗУ, однако понадобится больше памяти для загрузки live-системы.[1] Базовая установка занимает меньше 2 GiB дискового пространства. Поскольку для процесса установки требуется получать пакеты из удалённого репозитория, необходимо работающее интернет-соединение.

Contents

Перед установкой

Загрузка установочного образа

В зависимости от желаемого способа загрузки, скачайте образ ISO или netboot (а также соответствующую подпись GnuPG) со страницы Загрузки.

Проверка подписи

Рекомендуется проверять подпись образа перед его использованием, особенно когда он был загружен с зеркала HTTP, где загрузки обычно подвержены перехвату для подмены образа на вредоносный.

На системах с установленным GnuPG это можно сделать, поместив PGP signature (находится на странице Загрузки в разделе Checksums) в каталог с образом и выполнив команду:

В качестве альтернативы, можно проверить подпись из установленного Arch Linux:

Подготовка установочного носителя

Установочный образ можно загрузить на конечном устройстве с помощью USB-накопителя, оптического диска или сети (при помощи PXE) — следуйте соответствующей статье для подготовки установочного носителя.

Загрузка live-окружения

1. Загрузите устройство с установочного носителя с Arch Linux. Обычно при включении компьютера нажимается специальная клавиша (иногда она указывается на заставке) во время фазы POST для выбора загрузочного устройства. Обратитесь к руководству вашей материнской платы для получения более подробных инструкций.
2. Когда появится меню установочного носителя, выберите Arch Linux install medium и нажмите Enter для входа в установочное окружение.

Чтобы переключиться на другую виртуальную консоль в процессе установки (например, для просмотра этого руководства в Lynx), используйте горячие клавиши Alt+стрелка . Для редактирования файлов доступны программы mcedit(1) , nano и vim, см. также packages.x86_64 для получения списка пакетов, поставляемых в установочном образе.

Установка раскладки клавиатуры

По умолчанию используется раскладка консоли US. Чтобы посмотреть список доступных раскладок, запустите:

Чтобы изменить раскладку, добавьте имя соответствующего файла к команде loadkeys(1) , не указывая полного пути и расширения. Например, чтобы выбрать русскую раскладку, запустите:

Консольные шрифты расположены в каталоге /usr/share/kbd/consolefonts/ и могут быть выбраны при помощи setfont(8) .

Проверка режима загрузки

Чтобы проверить режим загрузки, просмотрите содержимое каталога efivars:

Если содержимое отображается без каких-либо ошибок, система загружена в режиме UEFI. Если же такого каталога не существует, возможно, система загружена в режиме BIOS (или CSM). Если система не загрузилась в желаемом режиме, обратитесь к руководству пользователя вашей материнской платы.

Соединение с интернетом

Для настройки сетевого соединения в live-окружении выполните следующие действия:

• Убедитесь, что ваш сетевой интерфейс обнаружен и включён, например, с помощью ip-link(8) :
• Если планируется использовать Wi-Fi, убедитесь, что беспроводная карта не заблокирована с помощью rfkill.
• Подключитесь к сети:
  • Ethernet: подключите кабель.
  • Wi-Fi: подключитесь к беспроводной сети с помощью iwctl.
• Настройте сетевые соединения:
  • DHCP: установка динамического IP-адреса и адреса DNS-сервера (при помощи systemd-networkd и systemd-resolved) должна срабатывать автоматически для проводных и беспроводных сетевых интерфейсов.
  • Статический IP: см. Настройка сети#Статический IP-адрес.
• Соединение можно проверить с помощью утилиты ping:

Синхронизация системных часов

Чтобы удостовериться, что время задано правильно, используйте timedatectl(1) :

Для проверки статуса службы используйте timedatectl status .

Разметка дисков

Когда запущенная система распознает накопители, они становятся доступны как блочные устройства, например, /dev/sda , /dev/nvme0n1 или /dev/mmcblk0 . Чтобы посмотреть их список, используйте lsblk или fdisk.

Результаты, оканчивающиеся на rom , loop и airoot , можно игнорировать:

На выбранном накопителе должны присутствовать следующие разделы:

Если вы хотите создать составное блочное устройство для LVM, шифрование диска или RAID, сделайте это сейчас.

Примеры схем

BIOS с MBR

Точка монтирования	Раздел	Тип раздела	Рекомендуемый размер
[SWAP]	/dev/раздел_подкачки	Linux swap	Более 512 МБ
/mnt	/dev/корневой_раздел	Linux	Остаток

UEFI с GPT

Точка монтирования	Раздел	Тип раздела	Рекомендуемый размер
/mnt/boot или /mnt/efi	/dev/системный_раздел_efi	системный раздел EFI	Более 260 MiB
[SWAP]	/dev/раздел_подкачки	Linux swap	Более 512 МБ
/mnt	/dev/корневой_раздел	Linux x86-64 root (/)	Остаток

Форматирование разделов

Когда новые разделы созданы, каждый из них необходимо отформатировать в подходящую файловую систему. Например, для форматирования /dev/корневого_раздела в Ext4 выполните следующую команду:

Если вы создали раздел для подкачки (swap), инициализируйте его с помощью утилиты mkswap(8) :

Для получения дополнительной информации смотрите раздел Файловые системы#Создание файловой системы.

Монтирование разделов

Смонтируйте корневой раздел в каталог /mnt . Например, если корневой раздел — /dev/корневой_раздел , выполните следующую команду:

Используя mkdir(1) создайте точки монтирования для всех остальных разделов (например, /mnt/efi ) и примонтируйте соответствующие разделы.

Если вы ранее создали раздел подкачки (swap), активируйте его с помощью swapon(8) :

В дальнейшем genfstab(8) обнаружит смонтированные файловые системы и пространство подкачки.

Установка

Выбор зеркал

Пакеты для установки должны скачиваться с серверов-зеркал, прописанных в файле /etc/pacman.d/mirrorlist . В установочном образе, после подключения к сети, reflector обновит список зеркал (выбрав 70 наиболее актуальных HTTPS-зеркал) и отсортирует их по скорости загрузки.[2]

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

Позже pacstrap скопирует этот файл в новую систему, так что это действительно стоит сделать.

Установка основных пакетов

Используйте скрипт pacstrap(8) , чтобы установить пакет base , ядро Linux и прошивки часто встречающихся устройств:

Пакет base не содержит все инструменты, имеющиеся на установочном носителе, из-за чего может потребоваться установка других пакетов для получения полностью функциональной базовой системы. В частности, рассмотрите возможность установки следующего программного обеспечения:

• утилиты для управления файловыми системами в пользовательском пространстве, которые будут использоваться в системе
• утилиты для доступа к RAID- или LVM-разделам
• специфические прошивки других устройств, не включённых в linux-firmware
• ПО, необходимое для организации сети
• текстовый редактор
• пакеты для доступа к документации в man и info: man-db , man-pages и texinfo

Чтобы установить другие пакеты или группы, добавьте их названия к команде pacstrap (разделяя их пробелом) или используйте pacman во время этапа #Chroot. Список пакетов на установочном носителе доступен на странице packages.x86_64.

Настройка системы

Fstab

Сгенерируйте файл fstab (используйте ключ -U или -L , чтобы для идентификации разделов использовались UUID или метки, соответственно):

После этого проверьте файл /mnt/etc/fstab и отредактируйте его в случае необходимости.

Chroot

Часовой пояс

Запустите hwclock(8) , чтобы сгенерировать /etc/adjtime :

Эта команда предполагает, что аппаратные часы настроены в формате UTC. Для получения дополнительной информации смотрите раздел System time#Time standard.

Локализация

Отредактируйте файл /etc/locale.gen , раскомментировав en_US.UTF-8 UTF-8 и другие необходимые локали (например, ru_RU.UTF-8 UTF-8 ), после чего сгенерируйте их:

Создайте файл locale.conf(5) и задайте переменной LANG необходимое значение:

Если вы меняли раскладку клавиатуры, сделайте это изменение постоянным в файле vconsole.conf(5) . Также добавьте шрифт для консоли с поддержкой кириллицы:

Настройка сети

Добавьте соответствующую запись в файл hosts(5) :

Если система имеет постоянный IP-адрес, его следует использовать вместо 127.0.1.1 .

Завершите настройку сети для вновь установленной среды, что также может включать в себя установку подходящего ПО для управления сетевым подключением.

Initramfs

Как правило, создание нового образа initramfs не требуется, поскольку pacstrap автоматически запускает mkinitcpio после установки пакета ядра.

Если вы используете LVM, системное шифрование или RAID, отредактируйте файл mkinitcpio.conf(5) и пересоздайте образ initramfs:

Пароль суперпользователя

Загрузчик

Выберите и установите загрузчик с поддержкой Linux. Если вы используете процессор Intel или AMD, включите также обновление микрокода.

Перезагрузка

Выйдите из окружения chroot, набрав exit или нажав Ctrl+D .

Вы можете размонтировать все разделы с помощью команды umount -R /mnt , чтобы убедиться в том, что ни один из разделов не остался занят какой-либо программой. Если нужно, для поиска таких программ используйте fuser(1) .

Теперь перезагрузите компьютер, набрав reboot : если какие-нибудь разделы остались смонтированными, systemd их размонтирует. Не забудьте извлечь установочный носитель. После загрузки войдите в систему в качестве суперпользователя.

После установки

Дальнейшие указания по настройке системы после установки (например, по настройке графического интерфейса, звука или тачпада) вы можете найти на странице Основные рекомендации.

Множество интересных и полезных программ вы найдете на странице Список приложений.

Источник

systemd (Русский)

systemd — набор базовых строительных кирпичиков Linux-системы. Представляет собой менеджер системы и служб, который выполняется как процесс с PID 1 и запускает остальную часть системы. systemd обеспечивает возможности агрессивной параллелизации, сокет- и D-Bus-активацию для запуска служб, запуск демонов по запросу, отслеживание процессов с помощью контрольных групп Linux, обслуживание точек (авто)монтирования, а также предлагает развитую транзакционную логику управления службами на основе зависимостей. systemd поддерживает сценарии инициализации SysV и LSB и работает как замена sysvinit. Среди прочих элементов и функций — демон журнала, утилиты управления базовой конфигурацией системы (имя хоста, дата, языковой стандарт), ведение списков вошедших в систему пользователей, запущенных контейнеров, виртуальных машин, системных учётных записей, каталогов и настроек времени выполнения, а также демоны для управления несложными сетевыми конфигурациями, синхронизации времени по сети, пересылки журналов и разрешения имён.

Contents

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

Главная команда для работы с systemd — systemctl. Она позволяет (среди прочего) отлеживать состояние системы и управлять системой и службами. Подробнее см. systemctl(1) .

Использование юнитов

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

При работе с systemctl обычно необходимо указывать полное имя юнита с суффиксом, например, sshd.socket . Существует несколько возможных сокращений:

• Если суффикс не указан, systemctl предполагает, что это .service. Например, netctl равнозначно netctl.service .
• Точки монтирования автоматически преобразуются в юнит .mount. Например, /home равнозначно home.mount .
• Аналогично точкам монтрования, имена устройств автоматически преобразуются в юнит .device. Например, /dev/sda2 равнозначно dev-sda2.device .

Если говорить точнее, systemd сначала попытается найти юнит, название которого полностью совпадёт с название@строка.суффикс , и лишь в случае неудачи создаст экземпляр шаблона название@.суффикс . Тем не менее, такие «конфликты» довольно редки, так как по соглашению символ @ должен использоваться только в названиях юнитов-шаблонов. Также помните, что вызвать юнит-шаблон без идентификатора экземпляра не получится, поскольку в этом случае нечего будет подставить вместо спецификатора %i .

Действие	Команда	Примечание
Анализ состояния системы
Состояние системы	$ systemctl status
Список запущенных юнитов	$ systemctl или $ systemctl list-units
Список юнитов, запустить которые не удалось	$ systemctl —failed
Список установленных файлов юнитов 1	$ systemctl list-unit-files
Информация о процессе по его PID	$ systemctl status pid	cgroup slice, занимаемая память и родительский процесс
Состояние юнита
Страница руководства юнита	$ systemctl help юнит	если юнит её предоставляет
Состояние юнита	$ systemctl status юнит	в т. ч. работает ли он в данный момент
Проверить, добавлен ли юнит в автозапуск	$ systemctl is-enabled юнит
Запуск, перезапуск, перезагрузка юнита
Незамедлительно запустить юнит	# systemctl start юнит
Незамедлительно остановить юнит	# systemctl stop юнит
Перезапустить юнит	# systemctl restart юнит
Перезагрузить юнит с новыми настройками	# systemctl reload юнит
Перезагрузить настройки systemd 2	# systemctl daemon-reload	сканировать систему на наличие новых или изменённых юнитов
Включение юнита (автозапуск)
Включить юнит, добавив его в автозапуск	# systemctl enable юнит
Включить юнит и сразу запустить	# systemctl enable —now юнит
Отключить юнит	# systemctl disable юнит
Включить юнит заново 3	# systemctl reenable юнит	т.е. отключить и снова включить
Маскировка юнита
Замаскировать юнит, сделав невозможным его запуск 4	# systemctl mask юнит
Снять маскировку юнита	# systemctl unmask юнит

1. В руководстве systemd.unit(5) § UNIT FILE LOAD PATH приведён перечень каталогов, в которых могут храниться файлы юнитов.
2. Перезагружаются только настройки systemd, но не юнитов. Для юнитов необходимо использовать команду reload.
3. Например, если раздел [Install] изменился с момента последнего включения.
4. Как вручную, так и по зависимости, что делает маскировку несколько опасной.

Управление питанием

Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальном пользовательском сеансе systemd-logind и нет других активных сеансов, приведенные ниже команды сработают, даже если будут выполнены не от root. В противном случае (например, другой пользователь вошел в систему через tty) systemd автоматически запросит у вас пароль суперпользователя.

Действие	Команда
Завершить работу и перезагрузить систему	$ systemctl reboot
Завершить работу и выключить компьютер	$ systemctl poweroff
Перевести систему в ждущий режим	$ systemctl suspend
Перевести систему в спящий режим	$ systemctl hibernate
Перевести систему в режим гибридного сна (suspend-to-both)	$ systemctl hybrid-sleep

Написание файлов юнитов

Синтаксис файлов юнитов systemd (см. systemd.unit(5) ) вдохновлён desktop-файлами XDG Desktop Entry Specification, а они, в свою очередь, основаны на синтаксисе файлов .ini Microsoft Windows. Файлы юнитов загружаются из целого ряда мест (команда systemctl show —property=UnitPath выведет полный список), ключевыми из которых являются следующие (в порядке увеличения приоритета):

• /usr/lib/systemd/system/ : юниты, добавленные пакетами при установке;
• /etc/systemd/system/ : юниты, созданные системным администратором.

При создании собственных юнитов за образец можно взять юниты установленных пакетов или примеры из systemd.service(5) § EXAMPLES .

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

В 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 запустит эту службу незамедлительно. Процесс при этом не должен разветвляться (fork). Если после данной службы должны запускаться другие, то этот тип использовать не стоит (исключение — служба использует сокетную активацию).
• Type=forking : systemd считает службу запущенной после того, как процесс разветвляется с завершением родительского процесса. Используется для запуска классических демонов за исключением тех случаев, когда в таком поведении процесса нет необходимости. Укажите параметр PIDFile= , чтобы systemd мог отслеживать основной процесс.
• Type=oneshot : удобен для сценариев, которые выполняют одно задание и завершаются. Если задать параметр RemainAfterExit=yes , то systemd будет считать процесс активным даже после его завершения.
• Type=notify : идентичен параметру Type=simple , но с уточнением, что демон пошлет systemd сигнал готовности. Реализация уведомления находится в библиотеке libsystemd-daemon.so.
• Type=dbus : служба считается находящейся в состоянии готовности после появления указанного BusName в системной шине DBus.
• Type=idle : systemd отложит выполнение двоичного файла службы до окончания запуска остальных («более срочных») задач. В остальном поведение аналогично Type=simple .

Редактирование файлов юнитов

Не стоит редактировать юнит-файлы пакетов напрямую, так как это приведёт к конфликтам с pacman. Есть два безопасных способа редактирования: создать новый файл, который полностью заменит оригинальный, или создать drop-in файл, который будет применяться поверх оригинального юнита. В обоих случаях после редактирования необходимо перезагрузить юнит, чтобы изменения вступили в силу. Это выполняется либо путем редактирования блока с помощью команды systemctl edit , которая автоматически перезагружает юнит, либо перезагрузкой всех юнитов командой:

Замещение файла юнита

Чтобы полностью заместить файл юнита /usr/lib/systemd/system/юнит , создайте файл с таким же именем /etc/systemd/system/юнит и включите заново юнит для обновления символических ссылок.

Эта команда откроет файл /etc/systemd/system/юнит в текстовом редакторе (если файл ещё не существует, будет скопирован оригинал) и автоматически перезагрузит юнит после завершения редактирования.

Drop-in файлы

Чтобы создать drop-in файл для /usr/lib/systemd/system/юнит , создайте каталог /etc/systemd/system/юнит.d/ и поместите в него файлы .conf с добавленными или изменёнными опциями. systemd будет анализировать эти файлы и применять их поверх оригинального юнита.

Самый простой способ — использовать команду:

Команда откроет /etc/systemd/system/юнит.d/override.conf в текстовом редакторе (файл будет создан, если его ещё нет) и автоматически перезапустит юнит после завершения редактирования.

Откат изменений

Отменить все изменения, сделанные с помощью systemctl edit , можно командой:

Примеры

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

Другой пример: для замены ExecStart в юните (кроме типа oneshot ) создайте следующий файл:

Обратите внимание, что ExecStart необходимо очистить перед присвоением нового значения [1]. Это относится ко всем параметрам, которые позволяют прописать несколько значений, вроде OnCalendar в таймерах.

Пример настройки автоматического перезапуска службы:

Systemd использует юнит типа цель (target) для группировки юнитов по зависимостям и в качестве стандартизированных точек синхронизации. Они выполняют ту же задачу, что и уровни запуска, но действуют немного по-другому. Каждая цель имеет имя, а не номер, и предназначена для конкретных задач; несколько целей могут быть активны одновременно. Некоторые цели реализованы путём наследования служб из других целей с добавлением собственных. В systemd также имеются цели, имитирующие общие уровни запуска SystemVinit, поэтому вы можете переключаться между целями, используя привычную команду telinit RUNLEVEL .

Получение информации о текущих целях

В systemd для этого предназначена следующая команда (заменяющая runlevel ):

Создание пользовательской цели

Уровни запуска, имеющие определённое значение в sysvinit (0, 1, 3, 5 и 6), один в один соответствуют конкретным целям systemd. К сожалению, не существует хорошего способа сделать то же самое для пользовательских уровней 2 и 4. Их использование предполагает, что вы создаёте новый юнит-цель с названием /etc/systemd/system/цель , который берет за основу один из существующих уровней запуска (взгляните, например, на /usr/lib/systemd/system/graphical.target ), создаёте каталог /etc/systemd/system/цель.wants , а после этого — символические ссылки на те службы из каталога /usr/lib/systemd/system/ , которые вы хотите включить при загрузке.

Соответствие уровней SysV целям systemd

Уровнень запуска 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 цели доступны посредством целевых юнитов. Вы можете переключать их такой командой:

Данная команда только изменит текущую цель и не повлияет на следующую загрузку системы. Она соответствует командам Sysvinit вида telinit 3 и telinit 5 .

Изменение цели загрузки по умолчанию

Стандартная цель — default.target , которая по умолчанию ссылается на graphical.target (примерно соответствующего прежнему уровню запуска 5).

Узнать текущую цель можно так:

Для установки новой цели загрузки по умолчанию измените ссылку default.target . С помощью команды systemctl это делается так:

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

• systemd.unit=multi-user.target (что примерно соответствует прежнему уровню запуска 3).
• systemd.unit=rescue.target (что примерно соответствует прежнему уровню запуска 1).

Порядок выбора цели по умолчанию

systemd выбирает default.target в следующем порядке :

1. Параметр ядра, описанный выше.
2. Символическая ссылка /etc/systemd/system/default.target .
3. Символическая ссылка /usr/lib/systemd/system/default.target .

Компоненты systemd

Некоторые (не все) составные части systemd:

• systemd-boot — простой менеджер загрузки для UEFI;
• systemd-firstboot — инициализация системных настроек при первой загрузке;
• systemd-homed — переносимые аккаунты пользователей;
• systemd-logind — управление сеансами;
• systemd-networkd — управление сетевыми настройками;
• systemd-nspawn — приложение для контейнеризации процессов;
• systemd-resolved — разрешение сетевых имён;
• systemd-sysusers(8) — создание системных пользователей/групп и добавление пользователей в группы при установке пакетов и загрузке системы;
• systemd-timesyncd — синхронизация системных часов по сети;
• systemd/Журнал — системные логи;
• systemd/Tаймеры — таймеры для управления событиями и службами, альтернатива cron.

systemd.mount — монтирование

systemd полностью отвечает за монтирование разделов и файловых систем, описанных в файле /etc/fstab . systemd-fstab-generator(8) преобразует записи из /etc/fstab в юниты systemd; это выполняется при каждой загрузке системы, а также при перезагрузке конфигурации системного менеджера.

systemd расширяет возможности fstab и предлагает дополнительные опции монтирования. Они могут влиять на зависимости юнита монтирования: например, могут гарантировать, что монтирование выполняется только после подключения к сети или после монтирования другого раздела. Полный список опций монтирования systemd (обычно они имеют префикс x-systemd ) описан в systemd.mount(5) § FSTAB .

Примером этих опций может быть т.н. автомонтирование (здесь имеется в виду не автоматическое монтирование во время загрузки, а монтирование при появлении запроса от устройства). Подробнее смотрите fstab#Автоматическое монтирование с systemd.

Автомонтирование GPT-раздела

На UEFI-системах systemd-gpt-auto-generator(8) автоматически монтирует GPT-разделы в соответствии с Discoverable Partitions Specification, поэтому их можно не указывать в файле fstab.

• Загрузчик должен установить EFI-переменную LoaderDevicePartUUID, по которой можно будет определить системный раздел EFI. Эта возможность поддерживается в systemd-boot, а также в rEFInd (по умолчанию отключена). Это проверяется наличием строки Boot loader sets ESP partition information в выводе команды bootctl .
• Корневой раздел должен быть на одном физическом диске с системным разделом EFI. Автомонтируемые разделы должны быть на одном физическом диске с корневым разделом. Очевидно, монтируемые разделы должны оказаться на одном диске и с ESP.

Для автомонтирования раздела /var его PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой:

systemd-sysvcompat

Пакет systemd-sysvcompat (зависимость пакета base ) содержит традиционный бинарный файл init. В системах под управлением systemd init — символическая ссылка на исполняемый файл systemd .

Кроме того, в этом пакете находятся 4 команды SysVinit — halt(8) , poweroff(8) , reboot(8) и shutdown(8) . Это символические ссылки на systemctl , и их работа обусловлена логикой systemd. Подробнее см. #Управление питанием.

В systemd-системах отказаться от совместимости с System V можно либо задав параметр загрузки init= (см. BBS#233387), либо с помощью собственных аргументов команды systemctl .

systemd-tmpfiles — временные файлы

Утилита systemd-tmpfiles создает, удаляет и очищает непостоянные и временные файлы и каталоги. Она читает конфигурационные файлы из /etc/tmpfiles.d/ и /usr/lib/tmpfiles.d/ , чтобы понять, что необходимо делать. Конфигурационные файлы в первом каталоге имеют приоритет над теми, что расположены во втором.

Конфигурационные файлы обычно предоставляются вместе с файлами служб и имеют названия вида /usr/lib/tmpfiles.d/программа.conf . Например, демон Samba предполагает, что существует каталог /run/samba с корректными правами доступа. Поэтому пакет samba поставляется в следующей конфигурации:

Конфигурационные файлы также могут использоваться для записи значений при старте системы. Например, если вы используете /etc/rc.local для отключения пробуждения от устройств USB при помощи echo USBE > /proc/acpi/wakeup , вместо этого вы можете использовать следующий tmpfile:

Советы и рекомендации

Программы настройки с графическим интерфейсом

• systemadm — Графический поисковик юнитов systemd. Выводит список юнитов, возможна фильтрация по типу.

https://cgit.freedesktop.org/systemd/systemd-ui/ || systemd-ui

• SystemdGenie — Утилита управления systemd на основе инструментов KDE.

https://invent.kde.org/system/systemdgenie || systemdgenie

Запуск сервисов после подключения к сети

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

Также должна быть включена служба ожидания сети того приложения, которое управляет сетью; только тогда network-online.target будет соответствовать состоянию сети.

• В NetworkManager служба NetworkManager-wait-online.service включается вместе с NetworkManager.service . Проверить состояние службы можно командой systemctl is-enabled NetworkManager-wait-online.service . Если служба не включена, то включите заново NetworkManager.service ещё раз.
• В случае netctlвключите службу netctl-wait-online.service .
• Для пользователей systemd-networkd юнит systemd-networkd-wait-online.service включается вместе со службой systemd-networkd.service ; проверьте это командой systemctl is-enabled systemd-networkd-wait-online.service . Если нет, то включите заново systemd-networkd.service .

Подробнее можно почитать в systemd wiki: Running services after the network is up.

Если служба отправляет DNS-запросы, она должна запускаться также после nss-lookup.target :

Чтобы цель nss-lookup.target работала как положено, должна быть служба, которая запускает её параметром Wants=nss-lookup.target и размещает себя перед ней ( Before=nss-lookup.target ). Обычно это выполняет локальный DNS-распознаватель.

Чтобы узнать, какие службы зависят от nss-lookup.target , выполните:

Включение установленных юнитов по умолчанию

This article or section needs expansion.

Arch Linux поставляется с файлом /usr/lib/systemd/system-preset/99-default.preset , в котором указан параметр disable * . Это означает, что systemctl preset отключает по умолчанию юниты и пользователь должен сам их включать после установки пакетов.

Если такое поведение не устраивает, создайте символическую ссылку /etc/systemd/system-preset/99-default.preset на /dev/null для переопределения файла конфигурации. Это заставит systemctl preset включать юниты новых пакетов — вне зависимости от типа — кроме указанных в других файлах из каталога настроек systemctl preset. Пользовательских юнитов это не касается. Подробнее смотрите systemd.preset(5) .

Песочница для приложений

Юнит может быть использован в качестве песочницы для изоляции приложений и их процессов в виртуальном окружении. Systemd использует механизм namespaces, белые и чёрные списки capabilities, а также control groups для контейнеризации процессов при помощи настраиваемых окружений — см. systemd.exec(5) .

Добавление к существующему юниту systemd функциональности песочницы обычно происходит методом проб и ошибок вкупе с использованием различных инструментов логирования — strace , stderr и journalctl(1) . В таких случаях имеет смысл предварительно поискать соответствующую документацию от разработчиков. В качестве отправной точки для поиска путей повышения безопасности изучите вывод команды:

Рекомендации по созданию песочницы с помощью systemd:

Параметр CapabilityBoundingSet определяет список разрешённых capabilities, но с его помощью можно также и запрещать некоторые capabilities для определённого юнита.
Например, можно задать capability CAP_SYS_ADM , необходимую для создания безопасной песочницы: CapabilityBoundingSet=

Уведомление о неработающих службах

Для уведомления о неудачном запуске службы используется директива OnFailure= в соответствующем файле службы или drop-in файле. Чтобы эта директива возымела эффект для всех служб одновременно, её необходимо добавть в drop-in файл верхнего уровня, см. systemd.unit(5) .

Создайте drop-in верхнего уровня:

Это добавит строку OnFailure=failure-notification@%n в файл каждой службы. Если какой-то_юнит завершится с ошибкой, запустится экземпляр службы failure-notification@какой-то_юнит для создания уведомления (или любой другой задачи, которая была назначена).

Создайте юнит-шаблон failure-notification@ :

После этого создайте сценарий failure-notification.sh , в котором определите, каким именно способом будет создаваться уведомление (mail, gotify, xmpp). Параметр %i будет заменён на название неудачно завершившегося юнита и будет передан сценарию в качестве аргумента.

Чтобы предотвратить регрессию экземпляров failure-notification@.service , создайте пустой файл drop-in настроек с именем, совпадающим с названием drop-in файла верхнего уровня (пустой файл «уровня служб» будет иметь приоритет над файлом «верхнего уровня»):

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

Неудачно запущенные службы

Следующая команда найдёт все службы, которые не смогли выполнить запуск:

Чтобы определить причину, по которой служба не запустилась, необходимо изучить записи её логов. Подробнее см. systemd/Журнал#Фильтрация вывода.

Диагностика загрузки системы

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

Диагностика службы

Если какая-либо служба systemd ведет себя не так, как ожидается, и вы хотите получить дополнительную информацию о том, что происходит, присвойте переменной окружения SYSTEMD_LOG_LEVEL значение debug . Например, чтобы запустить демон systemd-networkd в режиме отладки:

Добавьте drop-in файл для службы:

Или, как вариант, пропишите переменную окружения вручную:

После этого перезапустите systemd-networkd и следите за журналом службы с помощью опции -f / —follow .

Выключение/перезагрузка происходят ужасно долго

Если процесс выключения занимает очень долгое время (или выглядит зависшим), то, вероятно, виновата служба, которая не может завершить свою работу. Systemd ожидает некоторое время, пока каждая служба прекратит работу самостоятельно, и только потом пробует завершить её принудительно. Если вы столкнулись с такой проблемой, обратитесь к Shutdown completes eventually в systemd-вики.

По-видимому, процессы с кратким сроком жизни не оставляют записей в логах

Если команда 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 . В общем, это баг. Имейте в виду, что быстро падающие службы могут не успеть оставить сообщения в журнале из-за особенностей systemd.

Время загрузки системы увеличивается с течением времени

После использования systemd-analyze некоторые пользователи заметили, что время загрузки системы значительно увеличилось. После использования systemd-analyze blame NetworkManager запускался необычно долго.

Проблема связана с тем, что файл /var/log/journal стал слишком большим. При этом также может уменьшаться скорость работы других команд, например, systemctl status или journalctl . Для решения проблемы можно удалить все файлы из каталога журнала (в идеале — сделав где-нибудь резервные копии, хотя бы временно), а затем ограничить размер журнала.

systemd-tmpfiles-setup.service не запускается во время загрузки

Начиная с версии Systemd 219, /usr/lib/tmpfiles.d/systemd.conf определяет ACL-атрибуты для каталогов в /var/log/journal и, следовательно, требует включённой поддержки ACL для той файловой системы, в которой находится журнал.

Отключение emergency mode на удалённой машине

Вам может понадобиться отключить emergency mode на удалённой машине, например на виртуальных машинах Azure или Google Cloud. Это связано с тем, что в случае ухода системы в emergency mode она отключится от сети и лишит вас возможности подключения к ней.

Источник