Основы работы в ФС, iperf3, df, du, smartctl, iotop, iostat, top, htop, vmstat, systemctl, ps, strace, netstat, ifconfig, ip, traceroute, ping, mtr, tcpdump, syslog, dmesg, journalctl

Большая часть дисциплины - это изучение сетевых конфигураций. Это вам не два компа пинговать. Ансибле и прочее

http://www2.kangran.su/~nnz/pub/perf_rs/perf_rs_latest.pdf - книжонка по iptables

Что такое уровень выполнения (runlevel) в Linux и как посмотреть текущий?

Уровни выполнения (runlevel) Linux можно представить, как режим, в котором запускается система. Каждый из этих режимов обладают своими процессами, которые включены или выключены в зависимости от запущенного уровня выполнения. С момента загрузки Linux выполняется в одном из режимов, нельзя запускать систему одновременно в нескольких режимах, но есть возможность переключаться между уровнями во время работы на компьютере.

В системе Linux есть семь уровней выполнения, которые нумеруются от 0 до 6. Разные дистрибутивы по-разному используют уровни выполнения, так что очень сложно составить список задач, которые выполняет конкретный уровень.

Обычно уровни выполнения выглядят следующим образом:

Runlevel 0 завершает работу системы.
Runlevel 1 однопользовательский режим работы. Чаще всего используется в целях обслуживания и выполнения других административных задач. Это уровень также может называться runlevel S, где S означает single-user.

Цитата из systemd для администраторов Lennart Poettering

Дистрибутивно-специфичные квази-уровни исполнения, используемые для организации запуска скриптов на ранних стадиях загрузки, больше не поддерживаются. Примерами таких уровней являются S в Debian и b в openSUSE. Разумеется, это никак не затрагивает поддержку обычных уровней исполнения, которую мы намерены сохранять еще очень долго.

Runlevel 2 многопользовательский режим работы без поддержки сетевых служб (демонов).
Runlevel 3 многопользовательский режим с поддержкой сети, но без графического интерфейса. Чаще всего серверные версии Linux работают именно на этом уровне выполнения.
Runlevel 4 не используется. Пользователь может настраивать этот уровень исходя из его целей.
Runlevel 5 этот режим схож с уровнем 3, но тут еще запускается графический интерфейс. В этом режиме работают десктопные версии Linux.
Runlevel 6 этот уровень перезагружает систему.

TIP

Чтобы узнать текущий уровень выполнения достаточно ввести команду runlevel в командной строке. Текущий уровень выполнения можно менять командой telinit

Неа, в альте нет этого софта, этот софт не относится к временам systemd

Чтобы проверить текущий «runlevel» (уровень выполнения) в системе с systemd, используйте команду systemctl get-default для определения целевого юнита (target), который соответствует традиционному уровню запуска, или команду who -r, чтобы увидеть текущий уровень выполнения (хотя этот метод больше относится к классическим системам init).

Чтобы изменить текущий runlevel в системе с systemd, используйте команду sudo systemctl isolate <target>, где <target> — это название целевого объекта (target), например, multi-user.target для запуска в режиме командной строки или graphical.target для графического режима. Вы также можете изменить целевой объект по умолчанию, чтобы система загружалась в него при каждом запуске, используя команду sudo systemctl set-default <target>.

В последние годы systemd сменила многолетнюю систему уровней доступа (System V init). Фактически он работает по тому же принципу, но использует новые команды, которые в целом используют «runlevel» как «target»:

Runlevel 0 = poweroff.target (runlevel0.target)
Runlevel 1 = rescue.target (runlevel1.target)
Runlevel 2 = multi-user.target (runlevel2.target)
Runlevel 3 = multi-user.target (runlevel3.target)
Runlevel 4 = multi-user.target (runlevel4.target)
Runlevel 5 = graphical.target (runlevel5.target)
Runlevel 6 = reboot.target (runlevel6.target)

Цитата из systemd для администраторов Lennart Poettering

По умолчанию, уровни исполнения 2, 3 и 4 являются эквивалентами целевого состояния multi-user.target. Если включить службу на одном из них, то она будет включена и на остальных. Впрочем, это лишь настройка по умолчанию, и ничто не мешает вам определить их независимо. Тем не менее, мы рекомендуем отказаться от уровней исполнения в пользу более гибкого механизма целевых состояний systemd.

Теоретическая статья: Архитектура systemd — современная система инициализации Linux

Введение

systemd — это система инициализации (init-система) и менеджер служб, разработанный для замены традиционных init-систем на основе скриптов, таких как SysVinit. Впервые представленная в 2010 году Леннартом Пёттингом (Lennart Poettering), systemd быстро стала стандартом де-факто в большинстве дистрибутивов Linux, включая Fedora, Debian, Ubuntu, openSUSE и другие.

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

Архитектура systemd

systemd — это не просто init-процесс, а целая экосистема компонентов, объединённых под единым именем. Она построена вокруг центрального демона systemd, который запускается первым (PID 1) и управляет всей системой. Архитектура systemd построена по принципу модульности и интеграции, что позволяет ей управлять не только службами, но и устройствами, сессиями пользователей, сетевыми настройками и другими аспектами работы ОС.

Основные компоненты systemd

1. systemd (PID 1)

Центральный демон, запускаемый ядром при загрузке. Он:

Является родителем всех процессов (если они не запущены в изоляции).
Управляет жизненным циклом служб (unit’ов).
Обрабатывает зависимости между юнитами.
Реагирует на события от других компонентов (например, udev).
Реализует параллельный запуск служб для ускорения загрузки.

Особенности:

Использует асинхронную модель.
Поддерживает мониторинг состояния процессов через cgroups.
Предоставляет API для других компонентов.

2. systemd Units (юниты)

Юниты — это основная концепция systemd. Они представляют собой абстракции ресурсов системы: службы, сокеты, устройства, монтирования и т.д.

Типы юнитов:

.service — управление службами (демонами).
.socket — контроль за сокетами (сетевыми и Unix-сокетами), позволяя запускать службы по требованию.
.mount — управление точками монтирования файловых систем.
.swap — управление swap-разделами.
.target — группы юнитов, аналогичные runlevel’ам в SysVinit (например, multi-user.target, graphical.target).
.timer — планировщик задач, альтернатива cron.
.path — отслеживание изменений в файлах или путях.
.slice — логические группы для управления ресурсами (CPU, память) через cgroups.
.scope — временные группы процессов (например, созданные внешними процессами).
.automount — автоматическое монтирование при обращении.

Взаимосвязь: Юниты связаны через зависимости (Wants, Requires, After, Before, BindsTo и др.), что позволяет systemd строить граф запуска и корректно обрабатывать порядок инициализации.

3. journald

Система сбора и хранения журналов. Заменяет традиционные текстовые логи /var/log/messages и syslog.

Функции:

Централизованное хранение логов в бинарном формате (эффективное сжатие, индексация).
Поддержка структурированных данных (ключ-значение).
Автоматический сбор логов от всех процессов (включая stdout/stderr).
Интеграция с другими компонентами systemd.

Интерфейс: journalctl — утилита для просмотра и фильтрации логов.

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

4. logind

Управляет пользовательскими сессиями, входом в систему, спящим режимом, блокировкой экрана и питанием.

Функции:

Отслеживает сессии (локальные, графические, SSH).
Обрабатывает действия при закрытии ноутбука, нажатии кнопок питания.
Предоставляет D-Bus API для DE (GNOME, KDE и др.).
Контролирует доступ к устройствам (например, звук, графика) через seat.

Взаимосвязь: logind тесно интегрирован с systemd, polkit, udev и графическими средами. Создаёт юниты типа session-* и user-*.

5. networkd

Лёгкий демон для управления сетью. Предназначен для систем без сложных сетевых настроек (например, серверы, встраиваемые системы).

Функции:

Настройка интерфейсов (статические IP, DHCP, VLAN, бондинг, мосты).
Управление маршрутизацией.
Поддержка .network, .netdev, .link файлов.

Взаимосвязь: Может работать параллельно или вместо NetworkManager. Интегрируется с resolved и timesyncd.

6. resolved

Система разрешения имён (DNS, mDNS, LLMNR).

Функции:

Кэширование DNS-запросов.
Поддержка DNSSEC.
Работа с mDNS (для локальных имён, например, hostname.local).
Предоставление DNS через 127.0.0.53.

Взаимосвязь: Перехватывает запросы от приложений, интегрируется с networkd и nss-myhostname.

7. timesyncd

Лёгкий NTP-клиент для синхронизации времени.

Функции:

Синхронизация времени с NTP-серверами.
Автоматическое обновление системных часов.

Взаимосвязь: Альтернатива ntpd или chronyd. Работает в паре с timedated.

8. timedated

Управление системным временем и часовым поясом через D-Bus.

Функции:

Установка времени, даты, часового пояса.
Переключение между UTC и локальным временем.

Взаимосвязь: Работает с timesyncd, предоставляет API для DE и утилит (timedatectl).

9. udev (device management)

Хотя udev изначально был независимым проектом, теперь он тесно интегрирован в systemd.

Функции:

Обнаружение и управление устройствами (горячее подключение USB, дисков и т.п.).
Создание устройств в /dev.
Запуск правил при событиях (например, подключение флешки).

Взаимосвязь: systemd запускает systemd-udevd. События от udev могут запускать юниты systemd (например, монтирование диска).

10. systemd-boot (ранее gummiboot)

Простой загрузчик для систем с UEFI.

Функции:

Загрузка ядра Linux по стандарту UEFI.
Поддержка меню выбора ОС.
Безопасная загрузка (Secure Boot).

Взаимосвязь: Альтернатива GRUB. Интегрирован в systemd, но работает независимо от основного демона.

11. systemd-homed

Управление домашними каталогами пользователей в зашифрованном виде (в рамках проекта "Stateless Linux").

Функции:

Создание и монтирование зашифрованных домашних каталогов.
Поддержка профилей пользователей.

Взаимосвязь: Работает с logind и pam_systemd.

12. systemd-cryptsetup

Обеспечивает разблокировку шифрованных разделов (LUKS) при загрузке.

Взаимосвязь: Используется в initramfs для разблокировки корневой файловой системы.

Взаимосвязь компонентов

Все компоненты systemd работают в единой экосистеме, используя общие принципы:

D-Bus API — большинство компонентов (logind, resolved, timedated) предоставляют интерфейсы через D-Bus, что позволяет другим приложениям взаимодействовать с ними.
cgroups — systemd использует cgroups для отслеживания и изоляции процессов, что позволяет точно управлять ресурсами и определять, какие процессы принадлежат какой службе.
Асинхронность и параллельность — благодаря графу зависимостей, systemd может запускать службы параллельно, если их зависимости удовлетворены.
Единый конфигурационный формат — все юниты используют единый синтаксис (INI-подобный), что упрощает администрирование.
Интеграция с ядром — через udev и netlink, systemd получает события от ядра (например, подключение устройства).

Преимущества архитектуры systemd

Быстрая загрузка — параллельный запуск служб.
Централизованное управление — всё через systemctl, journalctl, loginctl и др.
Надёжность — мониторинг процессов, автоматический перезапуск.
Гибкость — поддержка on-demand запуска служб через сокеты.
Стандартизация — унифицированный подход в разных дистрибутивах.

Критика и альтернативы

Несмотря на популярность, systemd подвергается критике за:

Нарушение принципа "одна утилита — одна задача".
Сложность и монолитность.
Зависимость от D-Bus и других технологий.

Альтернативы:

OpenRC (в Gentoo, Alpine).
runit (в Void Linux).
s6 — лёгкая система инициализации.
sysvinit — классическая система.

Заключение

systemd — это не просто init-система, а полноценная платформа для управления современной Linux-системой. Её архитектура объединяет инициализацию, журналирование, управление сессиями, сетью и устройствами в единую согласованную систему. Благодаря модульности, глубокой интеграции и богатому функционалу, systemd стал неотъемлемой частью современных дистрибутивов Linux.

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

Литература:

Официальная документация systemd: https://www.freedesktop.org/wiki/Software/systemd/
man systemd, man systemd.unit, man journalctl
Lennart Poettering — "The Biggest Waste of Time in Computing History" (выступление о systemd)

Теоретическая статья: D-Bus — шина межпроцессного взаимодействия в Linux

Введение

D-Bus (Desktop Bus) — это система межпроцессного взаимодействия (IPC), разработанная для обеспечения стандартизированного способа обмена сообщениями между приложениями в операционных системах Linux и других Unix-подобных системах. Изначально созданная как часть проекта Freedesktop.org, D-Bus стала ключевым компонентом современных десктоп-сред (таких как GNOME и KDE), системных служб (включая systemd) и сервисов, требующих надёжной и структурированной коммуникации.

В этой статье мы рассмотрим архитектуру D-Bus, её основные концепции, компоненты, протокол и роль в экосистеме Linux.

Что такое D-Bus?

D-Bus — это механизм межпроцессного взаимодействия, позволяющий приложениям обмениваться сообщениями. Он работает по принципу шины (bus) — централизованного канала, к которому могут подключаться процессы для отправки и получения сообщений.

D-Bus решает следующие задачи:

Упрощение взаимодействия между процессами.
Предоставление стандартизированного API для системных и пользовательских служб.
Устранение дублирования функциональности (например, множества способов уведомить об изменении уровня звука).
Поддержка событийной модели (публикация/подписка).

Архитектура D-Bus

D-Bus построен по клиент-серверной архитектуре, но с использованием посредника — демона шины (message bus daemon), который маршрутизирует сообщения между процессами.

Основные компоненты:

Message Bus Daemon
Центральный процесс, управляющий шиной. Он отвечает за:
- Приём и маршрутизацию сообщений.
- Управление подключениями.
- Реализацию политик безопасности (через авторизацию).
Существует два основных экземпляра шины:
- System Bus — системная шина, доступная всем пользователям. Используется для взаимодействия с системными службами (например, systemd, NetworkManager, UPower).
- Session Bus — сессионная шина, запускается для каждого пользователя при входе в систему. Используется для общения приложений в рамках одной сессии (например, между GNOME Shell и приложением).
Клиенты (приложения)
Любой процесс, подключающийся к шине, становится клиентом. Он может:
- Отправлять сообщения.
- Получать сообщения.
- Экспортировать объекты и методы.
- Подписываться на сигналы.
Объекты, интерфейсы, методы и сигналы
D-Bus использует объектно-ориентированный подход к взаимодействию:
- Объект — сущность, доступная через шину, идентифицируемая object path (например, /org/freedesktop/NetworkManager).
- Интерфейс — набор методов и сигналов (аналог класса в ООП), например org.freedesktop.NetworkManager.Device.
- Методы — функции, которые можно вызывать удалённо (remote procedure call).
- Сигналы — события, которые объект может "испускать", а другие процессы — слушать (например, DeviceAdded).
Сообщения (Messages)
Все взаимодействия происходят через сообщения, которые бывают четырёх типов:
- Method Call — запрос на выполнение метода.
- Method Return — ответ на вызов метода.
- Error — сообщение об ошибке.
- Signal — широковещательное уведомление о событии.

Пример использования D-Bus

Представим, что приложение хочет узнать состояние Wi-Fi через NetworkManager:

Приложение подключается к System Bus.
Оно отправляет Method Call на объект /org/freedesktop/NetworkManager, интерфейс org.freedesktop.DBus.Properties, метод GetAll, с аргументом org.freedesktop.NetworkManager.
NetworkManager отвечает Method Return с данными о состоянии сети.
Приложение отображает информацию пользователю.

Если Wi-Fi-устройство подключается, NetworkManager отправляет сигнал DeviceAdded на шину, и все подписанные приложения получают уведомление.

Роль D-Bus в системе Linux

D-Bus играет ключевую роль в современных Linux-системах:

1. Интеграция с systemd

systemd использует D-Bus для предоставления API управления службами.
Команда systemctl на самом деле вызывает методы через D-Bus.
logind, networkd, resolved и другие компоненты systemd предоставляют свои интерфейсы через D-Bus.

2. Работа десктоп-окружений

GNOME и KDE активно используют D-Bus для:
- Уведомлений (org.freedesktop.Notifications).
- Управления питанием.
- Запуска приложений.
- Интеграции с апплетами панели.

3. Системные службы

NetworkManager — управление сетью.
UPower — мониторинг батареи.
BlueZ — Bluetooth-стек.
PulseAudio — звуковая система.

4. Безопасность и авторизация

Через polkit (PolicyKit) D-Bus позволяет запрашивать повышенные привилегии для выполнения действий (например, перезагрузка системы).
Политики доступа настраиваются в XML-файлах в /usr/share/dbus-1/system.d/.

Протокол и транспорт

D-Bus использует бинарный протокол, оптимизированный для эффективной передачи структурированных данных. Сообщения передаются через:

Unix-сокеты (локальные, наиболее распространённый способ).
TCP (редко, в специфических случаях).

Протокол включает:

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

Инструменты для работы с D-Bus

dbus-send — отправка методов вручную.

bash

dbus-send --system --dest=org.freedesktop.login1 --type=method_call /org/freedesktop/login1 org.freedesktop.login1.Manager.Reboot boolean:true

dbus-monitor — прослушивание всех сообщений на шине.
bash
```
dbus-monitor --system "interface='org.freedesktop.login1'"
```

busctl (часть systemd) — современная утилита для управления D-Bus.

bash

busctl list
busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager PowerOff boolean:true

d-feet — графический инспектор D-Bus (для отладки).

Преимущества D-Bus

Стандартизация — единый способ взаимодействия между компонентами.
Гибкость — поддержка RPC и событийной модели.
Безопасность — интеграция с ACL, polkit.
Эффективность — низкие накладные расходы благодаря бинарному протоколу.
Масштабируемость — работает как в сессиях пользователей, так и на системном уровне.

Критика и альтернативы

Несмотря на широкое распространение, D-Bus подвергается критике:

Сложность API.
Зависимость от центрального демона (точка отказа).
Избыточность в простых случаях.

Альтернативы:

Unix-сокеты напрямую — для простых IPC.
gRPC, ZeroMQ — в микросервисных архитектурах.
PipeWire — использует собственный IPC, но вдохновлён D-Bus.

Однако в контексте Linux-десктопа и системного уровня D-Bus остаётся доминирующим стандартом.

Заключение

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

Без D-Bus такие функции, как автоматическое обнаружение устройств, уведомления, управление питанием и интеграция systemd, были бы значительно сложнее в реализации. Понимание D-Bus необходимо для разработчиков системного ПО, администраторов и всех, кто хочет глубже понять, как работает Linux "под капотом".

Литература:

Официальный сайт D-Bus: https://www.freedesktop.org/wiki/Software/dbus/
Спецификация D-Bus: https://dbus.freedesktop.org/doc/dbus-specification.html
man dbus, man busctl, man systemd-bus-proxy
Lennart Poettering — выступления о D-Bus и systemd

Практические работы: Написание различных типов юнитов systemd

Введение

systemd — это мощная система инициализации Linux, которая управляется с помощью юнитов (units). Каждый юнит представляет собой конфигурационный файл, описывающий ресурс: службу, сокет, таймер, точку монтирования и т.д.

В этой практической работе вы научитесь создавать и управлять различными типами юнитов systemd:

.service — для управления демонами.
.socket — для активации служб по сокету.
.timer — для замены cron.
.mount — для монтирования файловых систем.
.path — для запуска по изменению файла.
.target — для группировки юнитов.

Общие правила

Юниты размещаются в:
- /etc/systemd/system/ — пользовательские (рекомендуется).
- /usr/lib/systemd/system/ — поставляемые пакетами (не редактировать напрямую).
После изменения файла выполните:
bash
```
sudo systemctl daemon-reload
```

Управление:

bash

sudo systemctl start имя_юнита
sudo systemctl stop имя_юнита
sudo systemctl enable имя_юнита   # автозапуск при загрузке
sudo systemctl status имя_юнита

Практическая работа 1: Создание `.service` — простой демон

Задача

Создать службу, которая каждые 10 секунд записывает метку времени в файл.

Шаги

Создайте скрипт:

bash

sudo nano /opt/hello-service.sh

bash

#!/bin/bash
while true; do
    echo "Hello from systemd $(date)" >> /var/log/hello.log
    sleep 10
done

Сделайте скрипт исполняемым:

bash

sudo chmod +x /opt/hello-service.sh
sudo touch /var/log/hello.log
sudo chown root:root /var/log/hello.log

Создайте юнит:

bash

sudo nano /etc/systemd/system/hello.service

ini

[Unit]
Description=Simple Hello Service
After=network.target

[Service]
Type=simple
ExecStart=/opt/hello-service.sh
Restart=always
User=root
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Перезагрузите конфигурацию и запустите:

bash

sudo systemctl daemon-reload
sudo systemctl start hello.service
sudo systemctl enable hello.service

Проверьте:

bash

sudo journalctl -u hello.service -f
cat /var/log/hello.log

Практическая работа 2: `.socket` — активация службы по сокету

Задача

Запустить службу только при обращении к TCP-сокету localhost:12345.

Шаги

Модифицируем службу (измените Type на simple → notify или forking не нужен, используем simple с socket activation):

bash

sudo nano /etc/systemd/system/echo.service

ini

[Unit]
Description=Echo Service
Requires=echo.socket

[Service]
Type=simple
ExecStart=/bin/nc -l -p 12345 -c 'echo "Hello from systemd socket!"'
StandardInput=socket

[Install]
Also=echo.socket

Создайте сокет:

bash

sudo nano /etc/systemd/system/echo.socket

ini

[Unit]
Description=Echo Socket

[Socket]
ListenStream=12345
Accept=false

[Install]
WantedBy=sockets.target

Запустите:

bash

sudo systemctl daemon-reload
sudo systemctl start echo.socket
sudo systemctl enable echo.socket

Проверьте:
bash
```
telnet localhost 12345
```
При первом подключении служба запустится автоматически.

Практическая работа 3: `.timer` — замена cron

Задача

Ежедневно в 9:00 утра очищать файл /var/log/hello.log.

Шаги

Создайте скрипт очистки:

bash

sudo nano /opt/clear-log.sh

bash

#!/bin/bash
> /var/log/hello.log
echo "Log cleared at $(date)" >> /var/log/clear.log

bash

sudo chmod +x /opt/clear-log.sh

Создайте службу:

bash

sudo nano /etc/systemd/system/clear-log.service

ini

[Unit]
Description=Clear log file

[Service]
Type=oneshot
ExecStart=/opt/clear-log.sh

Создайте таймер:

bash

sudo nano /etc/systemd/system/clear-log.timer

ini

[Unit]
Description=Run clear-log daily at 9:00
Requires=clear-log.service

[Timer]
OnCalendar=*-*-* 09:00:00
Persistent=true

[Install]
WantedBy=timers.target

Запустите:

bash

sudo systemctl daemon-reload
sudo systemctl start clear-log.timer
sudo systemctl enable clear-log.timer

Проверьте:

bash

systemctl list-timers
journalctl -u clear-log.service

Совет: OnCalendar поддерживает форматы:
daily, hourly, monthly
Mon *-*-* 10:00:00
*-*-1 00:00:00 — 1-го числа каждого месяца

Практическая работа 4: `.mount` — автоматическое монтирование

Задача

Автоматически монтировать раздел /dev/sdb1 в /mnt/data при загрузке.

Шаги

Убедитесь, что раздел существует и отформатирован:
bash
```
sudo mkfs.ext4 /dev/sdb1
```
Создайте точку монтирования:
bash
```
sudo mkdir -p /mnt/data
```

Создайте юнит:

bash

sudo systemd-escape --path /mnt/data
# Вывод: mnt-data.mount

bash

sudo nano /etc/systemd/system/mnt-data.mount

ini

[Unit]
Description=Mount Data Drive
Requires=dev-sdb1.device
After=dev-sdb1.device

[Mount]
What=/dev/sdb1
Where=/mnt/data
Type=ext4
Options=defaults

[Install]
WantedBy=multi-user.target

Включите:

bash

sudo systemctl daemon-reload
sudo systemctl start mnt-data.mount
sudo systemctl enable mnt-data.mount

Проверьте:
bash
```
mount | grep data
df -h /mnt/data
```

Практическая работа 5: `.path` — запуск по изменению файла

Задача

Следить за /tmp/trigger.txt и запускать скрипт при его создании.

Шаги

Создайте скрипт:

bash

sudo nano /opt/on-file-change.sh

bash

#!/bin/bash
echo "File triggered at $(date)" >> /var/log/path-trigger.log

bash

sudo chmod +x /opt/on-file-change.sh

Служба:

bash

sudo nano /etc/systemd/system/file-watch.service

ini

[Unit]
Description=Run on file change

[Service]
Type=oneshot
ExecStart=/opt/on-file-change.sh

Путь:

bash

sudo nano /etc/systemd/system/file-watch.path

ini

[Unit]
Description=Watch /tmp/trigger.txt

[Path]
PathExists=/tmp/trigger.txt

[Install]
WantedBy=multi-user.target

Запустите:

bash

sudo systemctl daemon-reload
sudo systemctl start file-watch.path
sudo systemctl enable file-watch.path

Проверьте:

bash

touch /tmp/trigger.txt
sleep 2
cat /var/log/path-trigger.log

Практическая работа 6: `.target` — группировка служб

Задача

Создать кастомный target maintenance.target, который останавливает сеть и запускает скрипт обслуживания.

Шаги

Создайте target:

bash

sudo nano /etc/systemd/system/maintenance.target

ini

[Unit]
Description=Maintenance Mode
AllowIsolate=yes

Создайте службу обслуживания:

bash

sudo nano /etc/systemd/system/maintenance-script.service

ini

[Unit]
Description=Maintenance Script
Before=maintenance.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo "Maintenance started at $(date)" >> /var/log/maintenance.log'
RemainAfterExit=yes

[Install]
WantedBy=maintenance.target

Отключите сеть при входе в target:

bash

sudo systemctl add-wants maintenance.target maintenance-script.service
sudo systemctl mask NetworkManager.service  # или network.service

Включите:

bash

sudo systemctl enable maintenance-script.service

Переключитесь:

bash

sudo systemctl isolate maintenance.target

Вернитесь:

bash

sudo systemctl isolate multi-user.target

Дополнительные советы

Проверка синтаксиса:

bash

systemd-analyze verify /etc/systemd/system/*.service

Автодополнение имён юнитов: Используйте Tab в systemctl.
Шаблонные юниты: Имя app@.service позволяет запускать app@instance1.service, app@instance2.service.
Переменные окружения: Используйте Environment= и EnvironmentFile= в [Service].

Заключение

В ходе этих практических работ вы освоили шесть ключевых типов юнитов systemd:

.service — основа для управления процессами.
.socket — эффективная активация по требованию.
.timer — гибкая замена cron.
.mount — управление точками монтирования.
.path — реакция на события в ФС.
.target — логическая группировка.

Эти навыки позволяют автоматизировать задачи, оптимизировать загрузку и создавать отказоустойчивые конфигурации.

Домашнее задание

Создайте таймер, который каждые 5 минут записывает нагрузку системы (uptime) в файл.
Настройте .socket, слушающий Unix-сокет /tmp/myservice.sock.
Сделайте так, чтобы при изменении /etc/hosts запускалось уведомление (через .path).

Источники:

man systemd.unit, man systemd.service, man systemd.socket
systemd-analyze dot | dot -Tpng > deps.png — визуализация зависимостей
https://www.freedesktop.org/wiki/Software/systemd/

Что такое уровень выполнения (runlevel) в Linux и как посмотреть текущий? ​

Введение ​

Архитектура systemd ​

Основные компоненты systemd ​

1. systemd (PID 1) ​

2. systemd Units (юниты) ​

3. journald ​

4. logind ​

5. networkd ​

6. resolved ​

7. timesyncd ​

8. timedated ​

9. udev (device management) ​

10. systemd-boot (ранее gummiboot) ​

11. systemd-homed ​

12. systemd-cryptsetup ​

Взаимосвязь компонентов ​

Преимущества архитектуры systemd ​

Критика и альтернативы ​

Заключение ​

Введение ​

Что такое D-Bus? ​

Архитектура D-Bus ​

Основные компоненты: ​

Пример использования D-Bus ​

Роль D-Bus в системе Linux ​

1. Интеграция с systemd ​

2. Работа десктоп-окружений ​

3. Системные службы ​

4. Безопасность и авторизация ​

Протокол и транспорт ​

Инструменты для работы с D-Bus ​

Преимущества D-Bus ​

Критика и альтернативы ​

Заключение ​

Практические работы: Написание различных типов юнитов systemd ​

Введение ​

Общие правила ​

Практическая работа 1: Создание .service — простой демон ​

Задача ​

Шаги ​

Практическая работа 2: .socket — активация службы по сокету ​

Задача ​

Шаги ​

Практическая работа 3: .timer — замена cron ​

Задача ​

Шаги ​

Практическая работа 4: .mount — автоматическое монтирование ​

Задача ​

Шаги ​

Практическая работа 5: .path — запуск по изменению файла ​

Задача ​

Шаги ​

Практическая работа 6: .target — группировка служб ​

Задача ​

Шаги ​

Дополнительные советы ​

Заключение ​

Что такое уровень выполнения (runlevel) в Linux и как посмотреть текущий?

Введение

Архитектура systemd

Основные компоненты systemd

1. systemd (PID 1)

2. systemd Units (юниты)

3. journald

4. logind

5. networkd

6. resolved

7. timesyncd

8. timedated

9. udev (device management)

10. systemd-boot (ранее gummiboot)

11. systemd-homed

12. systemd-cryptsetup

Взаимосвязь компонентов

Преимущества архитектуры systemd

Критика и альтернативы

Заключение

Введение

Что такое D-Bus?

Архитектура D-Bus

Основные компоненты:

Пример использования D-Bus

Роль D-Bus в системе Linux

1. Интеграция с systemd

2. Работа десктоп-окружений

3. Системные службы

4. Безопасность и авторизация

Протокол и транспорт

Инструменты для работы с D-Bus

Преимущества D-Bus

Критика и альтернативы

Заключение

Практические работы: Написание различных типов юнитов systemd

Введение

Общие правила

Практическая работа 1: Создание `.service` — простой демон

Задача

Шаги

Практическая работа 2: `.socket` — активация службы по сокету

Задача

Шаги

Практическая работа 3: `.timer` — замена cron

Задача

Шаги

Практическая работа 4: `.mount` — автоматическое монтирование

Задача

Шаги

Практическая работа 5: `.path` — запуск по изменению файла

Задача

Шаги

Практическая работа 6: `.target` — группировка служб

Задача

Шаги

Дополнительные советы

Заключение