Пакеты, сервисы и журналы

Предыдущие темы научили работать с файлами, правами, процессами и потоками данных. Программы, которыми пользуется человек за компьютером, кто-то собрал, разложил по каталогам и записал сведения о них в базу. Серверные программы должны работать постоянно и запускаться после перезагрузки, а при сбое нужно знать, где записаны сообщения об ошибках. Тема отвечает на три вопроса: как устанавливать и удалять ПО, как управлять фоновыми службами и как читать журналы. Для этого используются инструменты предыдущих тем: sudo из темы 4, понятия процесса и сигнала из темы 7, перенаправления из темы 5 и просмотр текста из темы 3.

Изложение идёт от пакетов к службам: сначала APT и база dpkg, затем загрузка системы, юниты systemd и, наконец, журналы. Примеры выполнялись в Ubuntu 22.04 под WSL2, где systemd не является процессом номер 1; там, где нужна работающая служба, вывод помечен как пример вывода. Целевая среда курса — Ubuntu 24.04. В ней версии пакетов и systemd новее, а юнит-файлы пакетов лежат в /usr/lib/systemd/system (в 22.04 путь записывался как /lib/systemd/system, и он по-прежнему доступен через ссылку /lib → /usr/lib). Структура вывода в обеих версиях совпадает.

Пакеты и менеджер пакетов

Что такое пакет и зачем нужны зависимости

Пакет (англ. package) — архив с программой, библиотеками, документацией и описанием: именем, версией, архитектурой и списком зависимостей. Без пакетов пользователь сам собирал бы программы и разбирался, каких библиотек не хватает. Общее описание пакетов и менеджеров для начинающих дано в книге Шоттса ¹. Пакетный менеджер решает это централизованно: мейнтейнер дистрибутива собирает программу один раз, проверяет совместимость и публикует результат в репозитории.

Пакеты связаны зависимостями (англ. dependencies). Программа curl использует библиотеку libcurl4 для сетевых запросов, а та, в свою очередь, — zlib1g для сжатия данных. Сведения о зависимостях записываются в описание пакета. Вот что сообщает APT о пакете curl в этой среде:

apt-cache depends curl

curl
  Depends: libc6
  Depends: libcurl4
  Depends: zlib1g

Строки Depends перечисляют то, без чего curl не будет работать. Обратная задача тоже важна: при удалении библиотеки нужно знать, кто от неё зависит. Вот обратные зависимости libcurl4 среди установленных пакетов:

apt-cache rdepends --installed libcurl4

libcurl4
Reverse Depends:
  curl
  curl

Список повторяет curl дважды; причину дубля проверьте сами (подсказка: apt-cache show curl). Главное следствие: менеджер не позволит удалить libcurl4, если без неё сломаются другие программы.

Репозитории, индексы и подписи

Пакеты хранятся в репозиториях — серверах или зеркалах. Чтобы знать, какие пакеты есть и какой версии, репозиторий публикует индекс: текстовый список пакетов, версий и контрольных сумм. Команда apt update обновляет локальную копию индексов; сами программы она не меняет.

Индексы подписываются ключом дистрибутива, поэтому подменить пакет на зеркале невозможно без подделки подписи. Контрольные суммы пакетов из индекса сверяются с загруженными файлами. Ключи хранятся в каталогах /usr/share/keyrings и /etc/apt/keyrings. В этой среде есть ключ архивов Ubuntu и ключ репозитория Docker.

Путь пакета показан на рисунке: APT получает индекс, проверяет подпись и выбирает пакеты с учётом зависимостей; dpkg распаковывает архивы и записывает каждый установленный файл в свою базу.

APT решает задачу «что установить и в каком порядке» и знает о репозиториях. dpkg работает с одним файлом пакета и не знает о сети; APT вызывает его внутри себя. Поэтому состав уже установленного пакета показывает dpkg, а поиск по репозиторию — APT.

Команды APT

Основной интерфейс пользователя к APT — команда apt с подкомандами. Для сценариев и скриптов рекомендуются apt-get и apt-cache: их формат вывода стабилен, а apt может меняться между версиями. В таблице перечислены основные действия.

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

apt-get -s install ncdu

NOTE: This is only a simulation!
      apt-get needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  ncdu
0 upgraded, 1 newly installed, 0 to remove and 36 not upgraded.
Inst ncdu (1.15.1-1 Ubuntu:22.04/jammy [amd64])
Conf ncdu (1.15.1-1 Ubuntu:22.04/jammy [amd64])

Строка The following NEW packages will be installed — главное место для проверки: здесь видно, какие пакеты добавятся, включая зависимости. Если в итоговой строке появляется ненулевое to remove, стоит разобраться, почему менеджер хочет что-то удалить.

apt-get -s install htop

NOTE: This is only a simulation!
      apt-get needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists...
Building dependency tree...
Reading state information...
htop is already the newest version (3.0.5-7build2).
0 upgraded, 0 newly installed, 0 to remove and 36 not upgraded.

Поиск и просмотр описания можно выполнить без прав root. Команда apt show выводит сведения из индекса, в том числе зависимости и размер:

apt-cache policy curl

curl:
  Installed: 7.81.0-1ubuntu1.29
  Candidate: 7.81.0-1ubuntu1.29
  Version table:
 *** 7.81.0-1ubuntu1.29 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        100 /var/lib/dpkg/status

Вывод apt-cache policy отвечает на два вопроса: какая версия установлена (Installed) и какая будет установлена при обновлении (Candidate). Звёздочка у строки версии отмечает установленную. Число 500 — приоритет источника: чем он выше, тем предпочтительнее источник. Строка 100 /var/lib/dpkg/status означает, что это сама база установленных пакетов. Если Installed и Candidate совпадают, обновлений нет.

Обновление индексов и установленных пакетов в учебной работе выполняется отдельной командой, потому что apt update не меняет программы, а apt upgrade меняет их, но не удаляет пакеты с конфликтующими зависимостями. Перед обновлением полезно посмотреть список доступных обновлений:

apt list --upgradable

Listing...
cloud-init/jammy-updates 26.1-0ubuntu1~22.04.1 all [upgradable from: 25.3-0ubuntu1~22.04.1]
containerd.io/jammy 2.4.1-2~ubuntu.22.04~jammy amd64 [upgradable from: 2.2.4-1~ubuntu.22.04~jammy]
dnsmasq-base/jammy-updates 2.91-0ubuntu0.22.04.2 amd64 [upgradable from: 2.90-0ubuntu0.22.04.4]

Строка [upgradable from: ...] показывает текущую версию и новую. Имя пакета записано вместе с источником через косую черту: jammy-updates — это ветка репозитория, из которой придёт обновление.

Источники пакетов: sources.list и sources.list.d

Список репозиториев задаётся в файлах источников; правила их записи описаны в документации Debian ³. Классический формат — однострочный, он хранится в файле /etc/apt/sources.list и в каталоге /etc/apt/sources.list.d/. В этой среде основной файл Ubuntu содержит строки такого вида:

grep -v '^#' /etc/apt/sources.list | grep . | head -3

deb http://archive.ubuntu.com/ubuntu/ jammy main restricted
deb http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted
deb http://archive.ubuntu.com/ubuntu/ jammy universe

Каждая строка описывает тип (deb — готовые пакеты, deb-src — исходные коды), адрес репозитория, кодовое имя выпуска (jammy) и компоненты (main, restricted, universe, multiverse). Компоненты отличаются лицензиями и уровнем поддержки: main поддерживается сообществом Ubuntu и Canonical, universe — сообществом. Сторонние репозитории обычно кладутся в /etc/apt/sources.list.d/ отдельными файлами. Вот файл репозитория Docker в этой среде:

cat /etc/apt/sources.list.d/docker.list

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable

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

В Ubuntu 24.04 основной файл записан в другом формате — DEB822, где каждый репозиторий описан блоком из полей ключ: значение, а блоки разделяются пустой строкой. Это пример вывода, так как в среде Ubuntu 22.04 такого файла нет:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Файл /etc/apt/sources.list.d/ubuntu.sources в Ubuntu 24.04 содержит именно такие блоки. Содержание полей то же, что и в однострочном формате: Types соответствует первому слову строки, URIs — адресу, Suites — кодовому имени, Components — компонентам, а Signed-By — ключу. Достаточно понимать, что оба формата описывают одно и то же, а менеджер читает оба.

Альтернативные способы установки

Наряду с APT существуют форматы, не зависящие от дистрибутива. Snap (Canonical) содержит собственные библиотеки и работает в изоляции; Flatpak решает похожую задачу для графических приложений. Они переносимы, но занимают больше места. Установка из исходного кода не записывает пакет в базу dpkg, поэтому обновлять и удалять программу придётся вручную. Для учебных задач почти всегда выбирается APT. В этой среде установлен snap, а flatpak нет (проверено командой which).

База dpkg и принадлежность файлов

База установленных пакетов

Менеджер dpkg хранит базу в каталоге /var/lib/dpkg. Каждый установленный пакет имеет запись о состоянии, версии и списке файлов. APT читает эту базу, чтобы знать, что уже установлено. Список установленных пакетов выводит dpkg -l. Ниже показаны три пакета из этой среды:

dpkg -l curl wget git

+++-==============-====================-============-=======================================================
ii  curl           7.81.0-1ubuntu1.29   amd64        command line tool for transferring data with URL syntax
ii  git            1:2.34.1-1ubuntu1.17 amd64        fast, scalable, distributed revision control system
ii  wget           1.21.2-2ubuntu1.5    amd64        retrieves files from the web

Первая колонка — два символа состояния: первый задаёт желаемое действие (i — установить), второй — фактическое состояние (i — установлен). Для установленного пакета оба символа образуют ii. Далее идут имя, версия, архитектура и краткое описание. Если в первой колонке стоит rc, пакет удалён, но его конфигурация осталась — это состояние после apt remove без purge.

Общее число установленных пакетов можно получить, подсчитав строки с состоянием ii:

dpkg -l | awk '$1=="ii"' | wc -l

936

Конструкция awk '$1=="ii"' выбирает строки, у которых первое поле равно ii; команда wc -l считает их. Инструменты awk и wc подробно разбираются в темах 5 и 6, здесь важно лишь то, что вывод dpkg -l является обычным текстом, который можно обрабатывать конвейером.

Какие файлы принадлежат пакету

Список файлов пакета выводит dpkg -L. Это полезно, когда нужно понять, куда пакет положил конфигурацию, документацию или исполняемый файл:

dpkg -L curl | head -8

/.
/usr
/usr/bin
/usr/bin/curl
/usr/share
/usr/share/doc
/usr/share/doc/curl
/usr/share/doc/curl/copyright

Список начинается с корня /. и содержит каталоги, которые пакет создаёт или в которых размещает файлы. Обратная задача — по файлу узнать, какой пакет его установил — решается командой dpkg -S. Сначала выясним путь к программе, а затем спросим, кому он принадлежит:

dpkg -S "$(which curl)"

curl: /usr/bin/curl

Конструкция $(which curl) — подстановка команды, которая будет разобрана в теме 13; здесь она подставляет путь /usr/bin/curl в команду dpkg -S. Ответ означает, что файл принадлежит пакету curl. Эта операция полезна при диагностике: если непонятно, откуда в системе взялась утилита, dpkg -S даёт ответ за секунду.

Теперь о важной ловушке. Попробуем спросить о том же файле по другому пути. Файл ls в этой среде лежит в /usr/bin, а /bin — символическая ссылка на /usr/bin:

ls -ld /bin /usr/bin

lrwxrwxrwx 1 root root     7 Jan  7  2025 /bin -> usr/bin
drwxr-xr-x 2 root root 36864 Oct 10 14:51 /usr/bin

dpkg -S /bin/ls
echo "код возврата: $?"
dpkg -S /usr/bin/ls
echo "код возврата: $?"

coreutils: /bin/ls
код возврата: 0
dpkg-query: no path found matching pattern /usr/bin/ls
код возврата: 1

Оба пути указывают на один и тот же файл, но dpkg записал его под именем /bin/ls, и сравнение идёт буквально по строке. Это следствие слияния каталогов (англ. usrmerge): /bin, /sbin и /lib в современных дистрибутивах являются ссылками на варианты в /usr. Запрос с «неправильным» путём даёт ответ «пакет не найден», хотя файл существует. Код возврата 1 позволяет проверять результат в скриптах.

Сведения о пакете

Сведения об установленном пакете выводит dpkg -s, а описание из репозитория — apt show или apt-cache show. Первые строки вывода dpkg -s для python3-minimal выглядят так:

dpkg -s python3-minimal | head -4

Package: python3-minimal
Status: install ok installed
Priority: optional
Section: python

Строка Status подтверждает установку. Поля Depends, Installed-Size, Maintainer и Description в том же выводе описывают зависимости, размер и сопровождающего. Журнал операций dpkg находится в /var/log/dpkg.log, а история команд APT — в /var/log/apt/history.log. Оба файла текстовые, и по ним можно восстановить, когда и какой пакет был установлен:

tail -n 3 /var/log/apt/history.log

Commandline: /usr/bin/unattended-upgrade
Upgrade: snapd:amd64 (2.76+ubuntu22.04.1, 2.76.3+ubuntu22.04.1)
End-Date: 2026-10-10  14:51:42

Запись содержит даты начала и конца операции, командную строку, из-за которой она выполнилась (здесь — автоматическое обновление unattended-upgrade), и список изменённых пакетов с версиями до и после. Именно такие записи помогают разобраться, почему программа вдруг изменилась после обновления.

Загрузка системы

Этапы загрузки

Чтобы понимать, какие службы запускаются автоматически и когда, полезно представлять путь от включения питания до приглашения входа. Загрузка проходит несколько этапов (рисунок). Прошивка (англ. firmware, в современных компьютерах UEFI) находит загрузчик, в Ubuntu это GRUB. Загрузчик загружает ядро Linux и начальную файловую систему initramfs. Ядро монтирует корневую файловую систему и запускает первый процесс пользовательского пространства с номером 1 — систему инициализации (англ. init system).

Init-система запускает всё остальное: монтирование файловых систем, сетевые службы, веб-серверы и прочие программы, которые работают постоянно. В Ubuntu это systemd. Её процесс с номером 1 — родитель всех остальных процессов, о котором шла речь в теме 7. Если он завершится, ядро паникует, поэтому systemd устроен как долгоживущий менеджер.

systemd как процесс номер 1

Проверить, какая программа является процессом номер 1, можно через /proc или через ps. В этой среде результат показывает, что систему запустил не systemd, а загрузчик WSL:

ps -p 1 -o pid,comm

  PID COMMAND
    1 init(Ubuntu-22.

Команда ps обрезает имя по длине колонки, поэтому init(Ubuntu-22. — это полное имя процесса, которое WSL задаёт сам. В этой среде пакет systemd установлен (версия 249 входит в Ubuntu 22.04), но он не является init-системой текущей сессии:

systemctl --version | head -1

systemd 249 (249.11-0ubuntu3.22)

systemctl is-system-running

offline

Состояние offline и сообщение System has not been booted with systemd as init system (PID 1) при обращении к systemctl означают, что команда видит пакет systemd, но не может с ним работать, потому что systemd не был запущен первым процессом. Такое состояние встречается в WSL2 без настройки systemd, в контейнерах и на системах с другим init. В разделе о WSL2 ниже показано, как включить systemd. Ниже в примерах управления службами вывод помечен как пример вывода, если он получен не в живой системе.

Юниты и их виды

Всё, чем управляет systemd, описывается юнитами (англ. units). Тип объекта задаётся расширением: .service — процесс, который systemd запускает, контролирует и перезапускает; .target — группа юнитов, соответствующая режиму работы, например multi-user.target; .socket — сокет, по которому служба запускается при первом подключении; .timer — запуск по расписанию, подробно в теме 16.

Администрирование служб и их файлов подробно описано в руководстве Немета и соавторов ². Юнит-файлы хранятся в /usr/lib/systemd/system (поставляются пакетами; в выводе Ubuntu 22.04 ниже этот каталог записан как /lib/systemd/system) и в /etc/systemd/system (файлы администратора). Одноимённый файл в /etc заменяет файл из /lib, поэтому пакет можно переопределить, не трогая его файлы. Какой пакет поставил юнит, покажет dpkg -S:

dpkg -S /lib/systemd/system/cron.service

cron: /lib/systemd/system/cron.service

Управление службами systemd

Команды systemctl

Команда systemctl — основной интерфейс к systemd; полный список её опций выводит man systemctl ⁵. Она отправляет запросы менеджеру systemd через системную шину и выводит ответ. В таблице перечислены команды, которые понадобятся в лабораторной работе. Все команды, кроме просмотра состояния, требуют прав root, поэтому в примерах используется sudo.

Важно различать start и enable. Команда start запускает службу в текущей сессии, но после перезагрузки она не вернётся, если не включён автозапуск. Команда enable ничего не запускает, она создаёт ссылку, по которой systemd запустит службу при загрузке. Это разделение похоже на различие между «запустить программу» и «добавить её в автозагрузку» в настольных системах, но в Linux оно выражено явно.

Вот как выглядит каталог, в котором systemd хранит включённые при загрузке службы. Каждая ссылка указывает на юнит-файл в /lib/systemd/system, а её существование и означает автозапуск:

ls -l /etc/systemd/system/multi-user.target.wants/ | head -4

total 0
lrwxrwxrwx 1 root root 41 Jan  7  2025 console-setup.service -> /lib/systemd/system/console-setup.service
lrwxrwxrwx 1 root root 38 Mar  2  2026 containerd.service -> /lib/systemd/system/containerd.service
lrwxrwxrwx 1 root root 32 Jan  7  2025 cron.service -> /lib/systemd/system/cron.service

Команда systemctl enable cron создала бы такую же ссылку cron.service в этом каталоге. Ссылка создаётся по секции [Install] юнит-файла, которую мы рассмотрим в разделе о собственной службе. Команда disable её удаляет. В живой системе systemctl status показывает строку Loaded (путь к юниту и признак enabled), строку Active (состояние), Main PID (главный процесс) и дерево CGroup со всеми процессами службы. Пример вывода здесь не приводится, потому что systemd в этой среде не запущен.

Состояния службы

Служба в systemd проходит состояния inactive (не запущена), activating (запускается), active (работает), deactivating (останавливается) и failed (завершилась с ошибкой и не перезапускается). Главное различие для эксплуатации — между inactive и failed: первое означает намеренную остановку, второе — сбой. Поэтому при диагностике сначала смотрят systemctl status, и только потом перезапускают службу.

Зависимости описываются в секции [Unit] директивами After, Requires и Wants. After задаёт только порядок запуска. Requires — жёсткую зависимость: если нужный юнит не запустился, зависимый не стартует. Wants — мягкую: сбой нужного юнита зависимый не останавливает. Поэтому веб-приложению, которому нужна сеть, пишут After=network.target: это задаёт очерёдность, но не гарантирует, что сеть реально работает.

Собственная служба: юнит-файл построчно

Структура юнит-файла

Юнит-файл — это текст в формате ini: секции в квадратных скобках и пары «имя = значение». Квадратные скобки здесь синтаксис самого файла, и в тексте мы их записываем только внутри кода. Рассмотрим реальный юнит-файл службы cron, поставленный пакетом. Он короткий и содержит все три основные секции:

cat /lib/systemd/system/cron.service

[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
After=remote-fs.target nss-user-lookup.target

[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS
IgnoreSIGPIPE=false
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

Секция [Unit] описывает юнит и его отношения с другими: название, документацию и порядок запуска. Секция [Service] содержит сведения о самом процессе: что запускать, с какими переменными окружения, как останавливать и при каком условии перезапускать. Секция [Install] нужна не во время работы службы, а при включении автозапуска командой enable: она задаёт, в какую цель добавить ссылку. Для cron это multi-user.target, то есть ссылка появится в каталоге multi-user.target.wants, который мы рассматривали выше.

Строка ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS требует пояснения. systemd не запускает программу через командную оболочку, поэтому $EXTRA_OPTS подставляет сам systemd из файла, заданного в EnvironmentFile=. Это не подстановка bash, и правила кавычек из темы 13 здесь не действуют. Такое отличие часто становится причиной ошибок: команда, которая работает в терминале, в юните может вести себя иначе, потому что в ней нет оболочки.

Синтаксис юнит-файла имеет ещё одно правило, которое легко нарушить. Комментарием считается только строка, начинающаяся с символа # или ;. Значение, записанное после знака равенства, тянется до конца строки, поэтому комментарий в конце строки попадает в значение. Если написать User=student # имя пользователя, systemd попытается запустить службу от пользователя с именем student # имя пользователя, которого не существует.

Директивы собственной службы

Для учебного приложения из лабораторной работы понадобится юнит, который запускает Python-сервер, перезапускает его при сбое и работает от обычного пользователя. В таблице перечислены директивы такого юнита, а сами значения проверены по документации systemd.service и systemd.exec.

По документации systemd ⁴, Type=simple — значение по умолчанию при заданном ExecStart=. Без User= служба работает от root, поэтому службу, которой не нужны права суперпользователя, запускают от обычной учётной записи. По умолчанию WorkingDirectory указывает на / — частая причина ошибок при запуске скриптов по относительному пути. Поэтому в шаблоне использованы абсолютные пути и к интерпретатору, и к скрипту.

Шаблон юнит-файла для лабораторной работы находится в окружении ЛР. Для иллюстрации здесь приведено его содержимое без комментариев, которые в самом файле занимают отдельные строки:

[Unit]
Description=Учебный HTTP-сервис лабораторной работы 9
After=network.target

[Service]
Type=simple
User=student
WorkingDirectory=/home/student/lab-09/lr-env
ExecStart=/usr/bin/python3 /home/student/lab-09/lr-env/app.py
Environment=APP_PORT=8080
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target

Проверка юнит-файла

Ошибки в юнит-файле systemd выявляет systemd-analyze verify без запуска службы. Он находит неизвестные директивы и секции, но не проверяет относительный путь к скрипту: команда ExecStart=python3 app.py синтаксически верна, а app.py ищется в каталоге /. Такую ошибку видно только при работе службы или при попытке выполнить команду вручную в каталоге systemd.

cd ~/lab-09/lr-env
systemd-analyze verify templates/app.service

/lib/systemd/system/snapd.service:23: Unknown key name 'RestartMode' in section 'Service', ignoring.

Предупреждение относится не к шаблону, а к системному юниту snapd.service, который проверяется вместе с нужными зависимостями. Это важно: вывод verify может содержать сообщения о чужих файлах, и нужно отличать их по пути в начале строки. Для неисправного юнита:

systemd-analyze verify broken.service

/lib/systemd/system/snapd.service:23: Unknown key name 'RestartMode' in section 'Service', ignoring.
/home/student/lab-09/lr-env/broken.service:7: Unknown key name 'Restart' in section 'Unit', ignoring.

Вторая строка указывает файл, номер строки и проблему: директива Restart записана в секции [Unit], где её нет, и systemd её игнорирует. Такую ошибку verify видит, а вот относительный путь в ExecStart — нет (см. выше). Поэтому verify стоит запускать до установки службы, а вторую ошибку искать выполнением команды вручную.

Перезапуск при сбое

Директива Restart=on-failure задаёт перезапуск, если процесс завершился ненулевым кодом, был убит сигналом или не ответил в срок. По таблице из документации systemd.service выход с кодом 0 перезапуска не вызывает, а сигналы SIGHUP, SIGINT, SIGTERM и SIGPIPE считаются чистым завершением. Поэтому systemctl stop не приводит к перезапуску: остановку инициировал сам systemd. Перезапуск касается только аварийного завершения.

Схема цикла показана на рисунке: служба падает, systemd ждёт RestartSec секунд и запускает её снова. При частых сбоях срабатывает ограничение частоты. Окно и число попыток задаются директивами StartLimitIntervalSec и StartLimitBurst секции [Unit]; по документации systemd-system.conf значения по умолчанию — 10 секунд и 5 запусков.

Проверим поведение самого учебного приложения. Сервис app.py при запросе /crash завершается с кодом 3 через os._exit, то есть так же, как упавшая программа. Запустим его на порту 8094, поскольку порт 8080 в этой среде уже занят, и проверим ответы. Запуск выполняется от пользователя без прав root, порт выше 1024:

cd ~/lab-09/lr-env
APP_PORT=8094 python3 app.py &
sleep 1
curl -s -i http://127.0.0.1:8094/

HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.10.12
Date: Mon, 12 Oct 2026 11:20:41 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 23

OK 2026-10-12 14:20:41

Конструкция & запускает процесс в фоне, а sleep 1 даёт серверу время открыть порт. Флаг -i в curl выводит заголовки ответа. Теперь обратимся к /crash и проверим код выхода процесса. Так как процесс запущен в фоне, код выхода получаем через wait:

APP_PORT=8092 python3 app.py > /tmp/app.log 2>&1 &
pid=$!
sleep 1
curl -s http://127.0.0.1:8092/crash
echo "код curl: $?"
wait $pid
echo "код выхода сервиса: $?"
cat /tmp/app.log

код curl: 52
код выхода сервиса: 3
2026-10-12 14:20:41,334 INFO сервис запущен на http://127.0.0.1:8092 (pid 32488)
2026-10-12 14:20:42,289 ERROR получен запрос /crash: аварийное завершение с кодом 3

Код curl 52 означает «пустой ответ сервера»: соединение оборвано до отправки заголовков. Код выхода 3 — ненулевой, поэтому при Restart=on-failure systemd перезапустил бы службу. Строка ERROR в журнале попала в stderr, а значит, при запуске под systemd она окажется в журнале journald. Теперь проверим реакцию на сигнал TERM, который systemd посылает при остановке:

APP_PORT=8093 python3 app.py > /tmp/app3.log 2>&1 &
pid=$!
sleep 1
kill -TERM $pid
wait $pid
echo "код выхода после SIGTERM: $?"

код выхода после SIGTERM: 143

Код 143 — это 128 плюс номер сигнала 15 (SIGTERM); так завершение по сигналу записывает оболочка. systemd хранит то же событие иначе: в журнале и в systemctl status будет code=killed, status=15/TERM, а не число 143. Согласно таблице systemd.service, SIGTERM относится к чистым завершениям, поэтому Restart=on-failure не перезапускает службу после systemctl stop. Сравнение двух кодов показывает, зачем systemd различает причины завершения: падение и остановка по команде означают разное.

Журналы системы

journald и классический syslog

Служба, которая пишет сообщения только в терминал, не годится для постоянной работы: после закрытия окна сообщения исчезают. Поэтому у systemd есть подсистема журналирования systemd-journald. Она собирает сообщения служб, ядра и самого systemd и хранит их в двоичном виде в /var/log/journal, поэтому читать журнал нужно программой journalctl, а не cat.

Классический способ — текстовые файлы в /var/log, которые ведёт демон syslog (в Ubuntu это rsyslog). В каталоге /var/log лежат привычные файлы: syslog с общими сообщениями, auth.log с входами и sudo, dpkg.log с установкой пакетов, а также подкаталоги, например apt/ для истории APT. Стандарт иерархии файловой системы (FHS) закрепляет назначение /var/log за файлами журналов ⁷. Список файлов в этой среде:

ls -l /var/log/syslog /var/log/dpkg.log

-rw-r--r-- 1 root   root  20070 Oct 10 14:51 /var/log/dpkg.log
-rw-r----- 1 syslog adm  518399 Oct 11 03:08 /var/log/syslog

Права на журналы — частая причина сообщения «Permission denied». Решение здесь — членство в группе adm, а не запуск от root.

Текстовые файлы в /var/log просматриваются командами из темы 3, а поиск — командами из темы 6. Строка классического журнала содержит время, узел, программу и сообщение. Пример ниже получен через journalctl, потому что в этой среде журнал systemd содержит те же записи, что и текстовый syslog:

journalctl --no-pager -u libvirtd -n 3 -o short

Oct 11 03:08:59 host systemd[1]: Stopping Virtualization daemon...
Oct 11 03:08:59 host systemd[1]: libvirtd.service: Deactivated successfully.
Oct 11 03:08:59 host systemd[1]: Stopped Virtualization daemon.

Имя узла в выводе заменено на host. Каждая строка содержит время, узел, программу с номером процесса в квадратных скобках (здесь systemd[1] — сам systemd) и сообщение. Квадратные скобки являются частью журнала, а не разметкой курса. Строка Deactivated successfully соответствует состоянию, о котором шла речь выше.

journalctl: основные опции

Команда journalctl читает журнал и умеет фильтровать записи. В таблице перечислены опции, которые понадобятся в лабораторной работе.

Уровни важности по убыванию серьёзности: emerg, alert, crit, err, warning, notice, info, debug. Фильтр -p err показывает все записи уровня err и выше, то есть также crit, alert и emerg. Вот примеры из журнала этой среды: список загрузок и записи об ошибках.

journalctl --list-boots --no-pager

-1 180512f1e7bb4b888c82de3940454374 Sun 2026-10-11 00:38:17 MSK—Sun 2026-10-11 01:53:49 MSK
 0 2bdde8f67ea34589be21980bb572437a Sun 2026-10-11 03:04:25 MSK—Sun 2026-10-11 03:09:00 MSK

Каждая строка описывает загрузку: номер относительно текущей (0 — текущая, -1 — предыдущая), идентификатор и интервал времени. Идентификатор нужен для точного указания загрузки в -b. Для поиска ошибок за период:

journalctl --no-pager -p err --since "2026-10-11 03:00" --until "2026-10-11 03:10" -o short

Oct 11 03:07:49 host libvirtd[330]: internal error: Network is already in use by interface virbr0
Oct 11 03:07:49 host libvirtd[330]: internal error: Failed to get udev device for syspath '/sys/devices/virtual/dmi/id'
Oct 11 03:08:59 host systemd[1]: Failed unmounting /init.

Фильтр по времени и уровню позволяет быстро сузить поиск, даже если журнал содержит миллионы записей. Опция -f в живой системе работает как tail -f и выводит записи по мере их появления. В этой среде она не демонстрируется, потому что журнал не растёт; при работе с собственной службой её стоит запускать во втором окне терминала и выполнять запрос /crash в первом. Журнал службы выводится командой journalctl -u app, если юнит называется app.service.

Уровень записи, по которому работает -p, задаёт не текст сообщения, а поле приоритета. Всё, что служба пишет в stdout и stderr, journald по умолчанию записывает с уровнем info, даже если в строке стоит слово ERROR. Чтобы строка получила другой уровень, программа начинает её с префикса в угловых скобках, как ядро: <3> — err, <4> — warning, <6> — info; journald распознаёт префикс (директива SyslogLevelPrefix=yes включена по умолчанию, см. systemd.exec ⁴) и удаляет его из текста. Учебный app.py добавляет такой префикс, только когда запущен под systemd: это видно по переменной окружения JOURNAL_STREAM, которую systemd передаёт службе. При ручном запуске префикса нет.

Ротация файловых журналов: logrotate

Текстовый журнал, в который программа дописывает строки, растёт без предела. Служба, которая пишет в файл годами, рано или поздно заполнит диск, а искать в файле на десятки гигабайт неудобно. Поэтому файловые журналы ротируют (англ. log rotation): когда файл достигает заданного возраста или размера, его переименовывают, программе выдают новый пустой файл, старые копии сжимают, а самые старые удаляют. Журнал journald в этом смысле устроен иначе: он сам следит за общим размером и удаляет старые записи, так что отдельная утилита для него не нужна. Ротация нужна именно файлам в /var/log и собственным журналам приложений ².

Для ротации в Ubuntu служит logrotate. Главный файл /etc/logrotate.conf содержит значения по умолчанию, а каталог /etc/logrotate.d/ — по одному файлу на пакет или службу; пакеты кладут туда свои настройки при установке. Вот главный файл без комментариев:

grep -v '^#' /etc/logrotate.conf | grep -v '^$'

weekly
su root adm
rotate 4
create
include /etc/logrotate.d

Читаем по строкам: ротировать раз в неделю, выполнять действия от имени root и группы adm (это нужно, потому что каталог /var/log принадлежит этой группе), хранить 4 старые копии, создавать новый файл после ротации, затем подключить файлы из /etc/logrotate.d. Пример настройки пакета, которая использует те же директивы:

cat /etc/logrotate.d/dpkg

/var/log/dpkg.log {
	monthly
	rotate 12
	compress
	delaycompress
	missingok
	notifempty
	create 644 root root
}

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

Директива delaycompress нужна потому, что программа могла ещё не закрыть переименованный файл, и сжимать его сразу рискованно; поэтому копию .1 оставляют несжатой до следующего раза. Хранение складывается из rotate и частоты: weekly и rotate 4 дают примерно месяц истории.

Здесь возникает главный вопрос ротации. Ротация переименовывает файл app.log в app.log.1, но программа, которая держит файл открытым, продолжает писать в тот же дескриптор, то есть уже в app.log.1 (дескриптор указывает на объект файла, а не на имя; см. раздел об открытых файлах в теме 7). Проверим это на учебной программе, которая пишет в журнал каждые 0,2 секунды. Ротируем без дополнительных действий и считаем строки через секунду.

  0 app.log
  7 app.log.1
  7 total
  0 app.log
 12 app.log.1
 12 total

Новый app.log остаётся пустым, а запись продолжается в app.log.1: ротация не достигла цели. Есть два способа исправить ситуацию.

• Сообщить программе, что нужно переоткрыть файл. Это делает блок postrotate, в котором обычно посылают сигнал, чаще всего SIGHUP (сигналы описаны в теме 7): программа закрывает старый файл и открывает файл по имени заново. Так устроены демоны вроде rsyslog и nginx, обработчик сигнала есть в самой программе. Если же обработчика нет, SIGHUP по умолчанию завершает процесс.
• Использовать copytruncate. Утилита копирует содержимое в app.log.1 и обнуляет исходный файл, не меняя его имени и дескриптора. Программе ничего не нужно знать, но между копированием и обнулением может потеряться несколько строк, а программа должна открывать файл в режиме дозаписи (в оболочке — 2>>app.log, а не 2>app.log), иначе после обнуления в файле появятся нули.

Оба варианта проверены на той же учебной программе: при postrotate с kill -HUP и при copytruncate новые записи оказываются в app.log, а прежние — в app.log.1.

== hup
  6 app.log
  5 app.log.1
== trunc
  6 app.log
  5 app.log.1

Конфигурацию проверяют без изменений в режиме отладки logrotate -d: он читает конфиг, печатает, что собирается сделать, но файлы не трогает. Принудительный запуск -f игнорирует расписание, а опция -s файл задаёт собственный файл состояния, в котором logrotate помнит время последней ротации каждого журнала. По умолчанию состояние лежит в /var/lib/logrotate/status и доступно только root; с собственным файлом всё работает без прав администратора, поэтому его удобно использовать для экспериментов. Создадим конфиг для журнала учебного приложения app.log, который приложение пишет через 2>>app.log.

cat > app-logrotate.conf <<CONF
$PWD/app.log {
    daily
    rotate 3
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}
CONF
logrotate -d -f -s state app-logrotate.conf

Вывод -d приведён с сокращением, путь заменён на /home/student/lab-09/lr-env. Сначала logrotate сообщает, какой файл рассматривает, затем принимает решение и перечисляет действия.

reading config file app-logrotate.conf
Reading state from file: state
Handling 1 logs

rotating pattern: /home/student/lab-09/lr-env/app.log  forced from command line (3 rotations)
empty log files are not rotated, old logs are removed
considering log /home/student/lab-09/lr-env/app.log
  log needs rotating
rotating log /home/student/lab-09/lr-env/app.log, log->rotateCount is 3
copying /home/student/lab-09/lr-env/app.log to /home/student/lab-09/lr-env/app.log.1
truncating /home/student/lab-09/lr-env/app.log

Настоящая ротация выполняется той же командой без -d. Ниже каталог после трёх запусков с новой записью в журнале между ними: свежая копия .1 не сжата (delaycompress), более старые сжаты и пронумерованы.

logrotate -s state -f app-logrotate.conf
ls -l

total 24
-rw-r--r-- 1 student student  129 app-logrotate.conf
-rw-r--r-- 1 student student    0 app.log
-rw-r--r-- 1 student student   62 app.log.1
-rw-r--r-- 1 student student   88 app.log.2.gz
-rw-r--r-- 1 student student  161 app.log.3.gz
-rw-r--r-- 1 student student 3104 app.py
-rw-r----- 1 student student   74 state

Файл состояния хранит время последней ротации; поэтому без -f повторный запуск в тот же день ничего не делает. Ошибки в конфигурации -d показывает сразу, не затрагивая файлы. Например, при rotate three вместо числа:

error: bad.conf:3 bad rotation count 'three'
error: found error in /tmp/lr/app.log , skipping

Надо помнить, что logrotate не работает постоянно: его запускает по расписанию таймер systemd logrotate.timer (в Ubuntu раз в сутки, OnCalendar=daily), который стартует службу logrotate.service. Поэтому директивы hourly и size не сработают чаще, чем таймер. Таймеры systemd и cron рассмотрены в теме 16.

Размер журнала journald ограничивается собственными настройками, а не logrotate. Сколько места занимают журналы, показывает journalctl --disk-usage, а предел задают директивы SystemMaxUse= (максимум для постоянного журнала в /var/log/journal), SystemKeepFree= (сколько места оставить свободным) и RuntimeMaxUse= (для журнала в памяти, /run/log/journal) в файле /etc/systemd/journald.conf или в фрагменте каталога /etc/systemd/journald.conf.d/ ⁴.

journalctl --disk-usage

Archived and active journals take up 21.3M in the file system.

По умолчанию journald занимает не более 10% файловой системы (но не более 4 ГБ) и оставляет свободными 15%. Однократное освобождение места выполняют командами sudo journalctl --vacuum-size=200M (оставить не более 200 МБ), --vacuum-time=2weeks (удалить записи старше двух недель) и --vacuum-files=N (оставить N файлов). Без root команда не может удалить архивные файлы:

Failed to delete archived journal /var/log/journal/e11e623ad3004c0899baa1dc2c127f74/system@00065d855eaada6e-19d1c40eb96d6822.journal~: Permission denied
Vacuuming done, freed 0B of archived journals from /var/log/journal/e11e623ad3004c0899baa1dc2c127f74.

С правами администратора вывод заканчивается строкой вида «Vacuuming done, freed 120.0M of archived journals» (пример вывода). Постоянное ограничение задают в конфигурации, например SystemMaxUse=200M, и применяют командой sudo systemctl restart systemd-journald.

journald в WSL2

В WSL2 systemd по умолчанию отключён, поэтому journald не запускается и журнал не ведётся, даже если пакет установлен. Включение выполняется в файле /etc/wsl.conf. Документация Microsoft описывает для этого секцию [boot] с параметром systemd=true ⁶. Файл редактируется от root, и изменения вступают в силу после полного закрытия дистрибутива из PowerShell:

[boot]
systemd=true

Команда wsl --shutdown выполняется в Windows и останавливает все работающие дистрибутивы, поэтому её запускают, когда работа не выполняется. После перезапуска systemctl is-system-running должна показать running или degraded, а не offline. Для systemd в WSL2 нужна версия WSL не ниже 0.67.6 (проверка: wsl --version в Windows).

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

Время и имя узла: timedatectl и hostnamectl

Журналы бесполезны, если время в них неверное: при разборе аварии записи разных машин сопоставляют по меткам времени. Поэтому systemd берёт под управление и базовые настройки системы. Команда timedatectl показывает и меняет время, часовой пояс и режим синхронизации, а hostnamectl — имя узла и сведения о системе. Обе обращаются к службам systemd (systemd-timedated и systemd-hostnamed) по шине D-Bus, поэтому работают только под управлением systemd.

Часы компьютера хранят время в UTC, а часовой пояс (англ. time zone) задаёт, как показывать его человеку: он выбирается ссылкой /etc/localtime на файл из базы часовых поясов /usr/share/zoneinfo. Синхронизацию с эталоном ведёт протокол NTP (англ. Network Time Protocol): в Ubuntu эту работу по умолчанию выполняет лёгкий клиент systemd-timesyncd, а на серверах с повышенными требованиями устанавливают chrony. Пример вывода timedatectl на машине с systemd (в этой среде команда не запускается, см. ниже):

               Local time: Sun 2026-10-18 19:51:11 MSK
           Universal time: Sun 2026-10-18 16:51:11 UTC
                 RTC time: Sun 2026-10-18 16:51:11
                Time zone: Europe/Moscow (MSK, +0300)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Строки читаются так: местное и всеобщее время; время аппаратных часов (RTC); часовой пояс с аббревиатурой и смещением; признак того, что часы синхронизированы; состояние службы NTP; хранятся ли аппаратные часы в местном времени (для Linux правильно no, значение yes встречается при двойной загрузке с Windows). Настройки меняет root:

Пример вывода hostnamectl, показывающий поля, полезные при отладке:

 Static hostname: host
       Icon name: computer-vm
         Chassis: vm
      Machine ID: e11e623ad3004c0899baa1dc2c127f74
         Boot ID: 2bdde8f67ea34589be21980bb572437a
  Virtualization: wsl
Operating System: Ubuntu 22.04.5 LTS
          Kernel: Linux 6.6.87.2-microsoft-standard-WSL2
    Architecture: x86-64

Этот пример получен в Ubuntu 22.04 под WSL2; в Ubuntu 24.04 отличаются версии в строках Operating System и Kernel, а более новый systemd может вывести и несколько дополнительных полей.

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

timedatectl

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

Нужные сведения доступны другими способами, которые работают и в WSL2: часовой пояс виден по файлу /etc/timezone и ссылке /etc/localtime, время — по date, имя узла — по hostname.

date; date -u
cat /etc/timezone
ls -l /etc/localtime

Sun Oct 18 19:56:03 MSK 2026
Sun Oct 18 16:56:03 UTC 2026
Europe/Moscow
lrwxrwxrwx 1 root root 33 Oct 18 13:33 /etc/localtime -> /usr/share/zoneinfo/Europe/Moscow

В WSL2 время обычно синхронизирует не NTP-клиент внутри дистрибутива, а виртуальная машина: ядро получает время от Hyper-V (в командной строке ядра есть параметр hv_utils.timesync_implicit=1), поэтому после выхода компьютера из сна часы дистрибутива могут отставать до очередной синхронизации. Если после сна время в журнале расходится с реальным, помогает команда sudo hwclock -s или перезапуск дистрибутива командой wsl --shutdown в Windows. Часовой пояс в WSL2 меняют правкой ссылки /etc/localtime (например, sudo ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime) или командой sudo dpkg-reconfigure tzdata. Имя узла хранится в /etc/hostname; в WSL2 его можно задать и параметром hostname секции network файла /etc/wsl.conf ⁶.

Подсистема аудита безопасности ядра: auditd

Отличие аудита от системных журналов

Стандартные службы журналирования (systemd-journald, rsyslog) работают в пространстве пользователя и пассивно принимают текстовые сообщения от программ. Если процесс скомпрометирован злоумышленником или администратор напрямую модифицирует бинарные файлы в обход стандартных утилит, в системный журнал ничего не попадёт.

Подсистема аудита ядра Linux Audit Framework (LAF) спроектирована для решения задач информационной безопасности и расследования инцидентов ⁸. Она встроена непосредственно в ядро Linux и перехватывает системные вызовы на входе и выходе из ядра ещё до того, как процесс получит результат. Демон auditd получает события ядра через специальный сокет Netlink (NETLINK_AUDIT) и асинхронно записывает их в защищённый журнал /var/log/audit/audit.log.

Конфигурация правил аудита: утилита auditctl

Правила аудита загружаются в ядро утилитой auditctl или автоматически из файлов каталога /etc/audit/rules.d/*.rules службой augenrules. Выделяют три основных класса правил:

1. Контроль целостности файлов и каталогов (File Watches):

   sudo auditctl -w /etc/shadow -p wa -k shadow_access
   sudo auditctl -w /etc/sudoers -p wa -k sudoers_tamper
   

   Флаг -w указывает путь, параметр -p wa задаёт отслеживаемые действия (w — запись, a — изменение атрибутов/прав), а метка -k (key) присваивает событию идентификатор для быстрого поиска в журнале.

2. Аудит системных вызовов (Syscall Rules):

   sudo auditctl -a always,exit -F arch=b64 -S execve -k command_execution
   

   Правило регистрирует каждый запуск исполняемых файлов через системный вызов execve в 64-битной архитектуре, фиксируя полный список переданных аргументов, текущий рабочий каталог, эффективный UID (euid) и исходный UID аутентификации (auid), который невозможно сбросить даже через команду sudo su.

3. Защита конфигурации аудита от отключения: Команда auditctl -e 2 переводит подсистему аудита ядра в заблокированный режим (immutable mode): ни одно правило не может быть изменено или выгружено до полной перезагрузки операционной системы, что предотвращает сокрытие следов нарушителем с правами root.

Поиск и отчёты: ausearch и aureport

Прямое чтение файла /var/log/audit/audit.log затруднено из-за сложного формата записей (тип события, временная метка epoch, шестнадцатеричные аргументы). Для криминалистического анализа применяются две штатные утилиты:

• ausearch — выборочный поиск событий:

  # Поиск всех попыток обращения к /etc/shadow по ключу:
  sudo ausearch -k shadow_access -i
  
  # Поиск событий сбоев аутентификации за последние сутки:
  sudo ausearch -m USER_AUTH -sv no -ts yesterday
  

  Флаг -i (interpret) автоматически переводит числовые UID в имена пользователей, а шестнадцатеричные строки аргументов — в читаемый текст.
• aureport — сводные статистические отчёты:

  sudo aureport -u --failed    # отчёт по неудачным попыткам входа пользователей
  sudo aureport -f -i          # сводка обращений к файлам
  sudo aureport -x --summary   # статистика запуска исполняемых файлов
  

Итоги темы

Пакеты — единица установки программного обеспечения: они описывают файлы, зависимости и подписи. APT получает индекс из репозитория, проверяет подпись, выбирает пакеты с учётом зависимостей и передаёт архивы dpkg, который распаковывает их и ведёт базу установленных файлов. Команды dpkg -L, dpkg -S и apt-cache policy показывают состав пакета, владельца файла и версии, а apt-get -s моделирует установку без прав root.

Загрузка заканчивается тем, что init-система запускает службы. В Ubuntu это systemd, работающий как процесс номер 1. Службы описываются юнитами, а команды systemctl управляют текущим запуском (start, stop) и автозапуском (enable, disable). Собственная служба оформляется юнит-файлом с секциями [Unit], [Service] и [Install]; надёжность обеспечивают Restart=on-failure, User и абсолютные пути. Ошибки синтаксиса выявляет systemd-analyze verify, а ошибки путей и рабочего каталога проявляются только при работе службы.

Журналы собирает journald, и читать их следует через journalctl, фильтруя по юниту, уровню и времени. Классические файлы в /var/log дополняют этот канал, а их права определяют, кто может их читать. Для работы служб и журналов в WSL2 нужно включить systemd в /etc/wsl.conf. Файловые журналы ротирует logrotate по конфигурации из /etc/logrotate.d; программу, которая держит журнал открытым, уведомляют сигналом в блоке postrotate или применяют copytruncate, а конфигурацию проверяют запуском logrotate -d и logrotate -f -s файл. Размер журнала journald ограничивается директивой SystemMaxUse= и командой journalctl --vacuum-size. Время, часовой пояс и имя узла находятся под управлением systemd (timedatectl, hostnamectl), а в WSL2 без systemd остаются date, hostname и файлы в /etc. Следующая тема переходит к дискам, разделам и файловым системам: блочные устройства, монтирование и файл /etc/fstab; монтирование тоже управляется systemd через юниты .mount. Таймеры systemd, которые заменяют cron и запускают logrotate, рассматриваются в теме 16.

Литература

1. Shotts W. The Linux Command Line: A Complete Introduction. 2nd ed. — No Starch Press, 2019. Открытая версия: https://linuxcommand.org/tlcl.php
2. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
3. Debian. Debian Reference / Debian Policy: пакеты и APT. — https://www.debian.org/doc/manuals/debian-reference/
4. systemd. Документация systemd.unit, systemd.service, systemd.timer, journalctl. — https://www.freedesktop.org/software/systemd/man/
5. The Linux man-pages project. — https://man7.org/linux/man-pages/
6. Microsoft. Документация WSL. — https://learn.microsoft.com/windows/wsl/
7. Linux Foundation. Filesystem Hierarchy Standard 3.0. — 2015. https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
8. Grubb S. Linux Audit Documentation and User Space Tools. — 2024. https://github.com/linux-audit/audit-documentation

Дополнительные материалы

Вопросы для самопроверки

1. Чем пакет отличается от архива с программой? Какие сведения хранятся в описании пакета?
2. Какую задачу решает индекс репозитория, и зачем apt update нужен отдельно от apt upgrade?
3. Почему менеджер пакетов проверяет подпись индекса, и где хранятся ключи в Ubuntu 22.04 и 24.04?
4. Что показывает apt-get -s install имя, и почему симуляция не требует прав root?
5. Чем apt remove отличается от apt purge? Что означает состояние rc в выводе dpkg -l?
6. Какой пакет установил файл /usr/bin/curl, и какой командой это проверяется?
7. Почему dpkg -S /usr/bin/ls может не находить файл, которого нет в базе под этим именем? Какое свойство системы вызывает такой эффект?
8. Что изменится в системе, если выполнить systemctl enable для службы, а не systemctl start?
9. Почему WorkingDirectory по умолчанию указывает на /, и как это влияет на относительный путь в ExecStart?
10. Какие значения Restart= перезапускают службу после выхода с кодом 3, а какие — после systemctl stop?
11. Что произойдёт со службой, если сработает ограничение StartLimitBurst, и как вернуть её в рабочее состояние?
12. Почему комментарий в конце строки юнит-файла превращается в часть значения, и как это проверить командой systemd-analyze verify?
13. Какой фильтр journalctl выберет ошибки текущей загрузки, а какой — записи службы за последний час?
14. Почему в WSL2 без включённого systemd команда systemctl не работает, хотя пакет systemd установлен?
15. Зачем ротировать файловые журналы и почему journald не нужна отдельная ротация? Что делают директивы rotate 4, compress, delaycompress, missingok, notifempty?
16. Почему после ротации программа продолжает писать в app.log.1? Чем postrotate с сигналом отличается от copytruncate, и какой недостаток у второго способа?
17. Как проверить конфигурацию logrotate без изменения файлов и как выполнить ротацию без root? Для чего нужен файл состояния?
18. Как ограничить размер журнала journald и узнать, сколько места он занимает?
19. Что показывают timedatectl и hostnamectl и почему они не работают в WSL2 без systemd? Какими командами узнать время, часовой пояс и имя узла в этом случае?
20. В чём фундаментальное отличие подсистемы аудита ядра auditd от прикладных служб журналирования rsyslog и journald при расследовании несанкционированных действий?
21. Как работают правила auditctl для отслеживания записи в файлы (-w /etc/shadow -p wa) и перехвата запуска процессов (-S execve)? Что фиксирует метка идентификатора сессии auid?
22. Как с помощью утилит ausearch и aureport провести выборочный поиск событий безопасности и построить статистический отчёт по отказам в доступе?

Глоссарий темы

Шпаргалка

Типичные ошибки

1. Симптом: Unit app.service could not be found или systemctl status не находит службу. Причина: юнит-файл не скопирован в /etc/systemd/system или не выполнена перечитка конфигурации. Исправление: sudo cp app.service /etc/systemd/system/ и sudo systemctl daemon-reload.

2. Симптом: служба в состоянии failed, в журнале can't open file '/app.py'. Причина: в ExecStart указан относительный путь к скрипту, а рабочий каталог службы по умолчанию — /. Исправление: указать абсолютный путь к app.py и задать WorkingDirectory=.

3. Симптом: служба не перезапускается после падения, а в журнале нет записи о перезапуске. Причина: директива Restart= записана в секции [Unit], где systemd её игнорирует. Исправление: перенести Restart= в секцию [Service]; проверка через systemd-analyze verify, которая выводит Unknown key name с номером строки.

4. Симптом: User=student # комментарий приводит к ошибке запуска с неизвестным пользователем. Причина: в юнит-файле комментарии допускаются только отдельными строками, а остаток строки после знака равенства становится значением. Исправление: перенести комментарий на отдельную строку, начинающуюся с #.

5. Симптом: dpkg -S /usr/bin/ls возвращает «no path found», хотя ls установлен. Причина: пакет записал файл под именем /bin/ls, а dpkg сравнивает пути буквально. Исправление: искать по пути, записанному в базе: dpkg -L coreutils | grep "/ls$" покажет /bin/ls, а dpkg -S /bin/ls вернёт владельца.

6. Симптом: systemctl status выводит System has not been booted with systemd. Причина: systemd не является процессом номер 1 (типично для WSL2 без настройки). Исправление: включить systemd в /etc/wsl.conf и выполнить wsl --shutdown в Windows.

7. Симптом: Permission denied при чтении /var/log/syslog. Причина: файл принадлежит группе adm, а пользователь в неё не входит. Исправление: проверить членство через id; читать журнал через journalctl, если права не позволяют.

8. Симптом: после ошибки в юнит-файле служба просто не стартует, а verify показывает предупреждение, которое не понятно. Причина: предупреждение относится к другому файлу (например, snapd.service). Исправление: смотреть на путь в начале строки предупреждения и номер строки.

9. Симптом: после ротации новый app.log пуст, а новые записи появляются в app.log.1. Причина: программа держит старый файл открытым, и переименование не меняет её дескриптор. Исправление: copytruncate или postrotate с сигналом, на который программа переоткрывает файл.

10. Симптом: после ротации служба завершилась, в журнале Hangup. Причина: в postrotate послан SIGHUP программе без обработчика, а действие по умолчанию — завершение. Исправление: убрать сигнал и применить copytruncate либо добавить обработчик в программу.

11. Симптом: logrotate ничего не делает, ошибок нет. Причина: путь в конфиге ошибочен, а missingok скрывает отсутствие файла; либо ротация уже была сегодня по файлу состояния. Исправление: запустить logrotate -d -s state файл.conf и прочитать строки does not exist или does not need rotating; для проверки добавить -f.

12. Симптом: bad rotation count или missing '{' after log files definition. Причина: в rotate не число или не закрыт блок. Исправление: прочитать номер строки в сообщении logrotate -d.

Что почитать и посмотреть

1. Shotts W. The Linux Command Line — открытая версия на linuxcommand.org (https://linuxcommand.org/tlcl.php). Главы о пакетах и процессах; понятный текст для первого знакомства с системой.
2. Debian Reference (https://www.debian.org/doc/manuals/debian-reference/). Подробное описание APT, репозиториев и dpkg; применимо к Ubuntu, которая основана на Debian.
3. Документация systemd (https://www.freedesktop.org/software/systemd/man/). Страницы systemd.unit, systemd.service, systemd.exec и journalctl; первоисточник для всех директив темы.
4. Страницы руководства на man7.org (https://man7.org/linux/man-pages/). Например, man systemctl, man journalctl, man dpkg; удобно искать по имени команды.
5. Nemeth E. и соавторы, UNIX and Linux System Administration Handbook. Главы о программном обеспечении и службах; подробный практический справочник администратора.
6. Документация WSL от Microsoft (https://learn.microsoft.com/windows/wsl/). Раздел о включении systemd через /etc/wsl.conf и о версиях WSL.
7. Filesystem Hierarchy Standard 3.0 (https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html). Назначение /var/log, /etc и /lib и почему систему удобно читать по стандарту.
8. explainshell.com — разбор команды по частям с описанием каждой опции; удобно проверить, например, journalctl -u app -p err --since "10 min ago".
9. Для тренировки: OverTheWire Bandit (https://overthewire.org/wargames/bandit/) — задания на работу с файлами и правами, которые закрепляют навыки этой и предыдущих тем.

Лабораторная работа 9. Сервис учебного приложения

• Раздел курса: тема 9 «Пакеты, сервисы и журналы»

Введение

В теории темы 9 описаны пакеты и менеджер APT, база dpkg, загрузка системы, юниты systemd и журналы journald. В этой работе эти понятия применяются на практике: исследуется установленное программное обеспечение, находится владелец файла, простое Python-приложение оформляется как служба systemd, включается автозапуск, вызывается аварийное завершение и наблюдается перезапуск в журнале.

Дополнительно работа показывает, как не дать журналу приложения разрастись: журнал в файле ротируется утилитой logrotate, и в конфигурации ротации нужно найти и исправить ошибки.

Работа состоит из основной (базовой) части (части 1–6) и продвинутой (углублённой, по желанию) части (части 7–8). Часть 8 не требует ни sudo, ни systemd. Для выполнения части 4 и последующих нужна работающая init-система systemd: в Ubuntu 24.04 она запускается по умолчанию, в WSL2 её нужно включить в /etc/wsl.conf (см. теорию, раздел о журналах в WSL2). Если systemd включить не удаётся, части 1–3 выполняются полностью, а части 4–6 — по образцу вывода, приведённому в описании.

Цель работы

Освоить установку и исследование пакетов, найти владельца файла, оформить и запустить собственную службу systemd с перезапуском при сбое и разобрать её записи в журнале.

После выполнения работы получится:

• определить, какой пакет установил файл, и перечислить файлы пакета командами dpkg -S и dpkg -L;
• предсказать результат apt-get -s install и объяснить список пакетов, который показывает симуляция;
• оформить юнит-файл службы с секциями [Unit], [Service] и [Install] и проверить его командой systemd-analyze verify;
• включить автозапуск службы и управлять её состоянием командами systemctl;
• объяснить по журналу, почему служба перезапустилась, и отличить аварийное завершение от остановки командой;
• находить и исправлять ошибки в юнит-файле;
• (продвинутая часть) настроить ротацию файлового журнала приложения в logrotate, проверить её с -d и -f -s без root и объяснить разницу между postrotate с сигналом и copytruncate.

Теоретический минимум

Необходимый материал изложен в теории темы 9: разделы «Пакеты и менеджер пакетов», «База dpkg и принадлежность файлов», «Управление службами systemd», «Собственная служба: юнит-файл построчно» и «Журналы системы».

Команды и опции, которые понадобятся в работе:

Структура учебного окружения такова: приложение app.py слушает порт на адресе 127.0.0.1, отвечает на / строкой с временем и при запросе /crash завершается с кодом 3. Порт задаётся переменной APP_PORT. Журнал приложения пишется в stderr, поэтому при запуске под systemd он попадает в journalctl; строки ERROR получают уровень err благодаря префиксу <3> (см. теорию, раздел «journalctl: основные опции»).

Перечень оснащения

Ubuntu 24.04 (в Ubuntu 22.04 работа выполняется так же; отличаются версии пакетов и путь /lib/systemd/system вместо /usr/lib/systemd/system в выводе) или WSL2 с включённым systemd. Нужны пакеты python3 и curl; установка при их отсутствии:

sudo apt update
sudo apt install -y python3 curl

Права sudo нужны для установки службы и для команд systemctl, которые меняют состояние. Архив окружения: lr-env. В архиве находятся app.py — приложение; templates/app.service — шаблон юнит-файла; broken.service — неисправный юнит для задания по поиску ошибки; broken-logrotate.conf — неисправная конфигурация ротации для части 8; README.md — описание окружения.

Порядок выполнения работы

Архив распаковывается в каталог ~/lab-09, внутри которого появится подкаталог lr-env; все команды работы выполняются в ~/lab-09/lr-env:

unzip ~/Downloads/lr-env.zip -d ~/lab-09 && cd ~/lab-09/lr-env
ls

Работа ведётся по схеме «предсказать — проверить — объяснить». Перед каждой командой, которая меняет систему или выводит существенный результат, запишите в журнал работы ожидаемый ответ. После выполнения сравните его с выводом. Если они различаются, объясните расхождение; такие объяснения составляют основную часть журнала работы. Команды, требующие sudo, выполняются на собственной машине; их вывод в тексте помечен как пример вывода, а фиксировать нужно свой вывод.

Часть 1. Пакеты: состав и владелец файла

Задание

1. Установлен ли пакет ncdu? Предскажите ответ, затем проверьте командой apt-cache policy ncdu. Что означают строки Installed и Candidate?
2. Выполните симуляцию установки apt-get -s install ncdu. Какие пакеты будут установлены и сколько? Почему симуляция не требует sudo и ничего не меняет?
3. Найдите путь к утилите curl командой command -v curl, затем её владельца командой dpkg -S "$(command -v curl)". Перечислите первые пять строк dpkg -L curl.
4. Выясните владельца файла /usr/bin/python3 и файла /bin/ls. Предскажите, что вернёт dpkg -S /usr/bin/ls, и проверьте. Объясните результат, если он отличается от ожидаемого.
5. Проверьте, есть ли владелец у /etc/passwd: выполните dpkg -S /etc/passwd и дайте объяснение коду возврата.
6. Подсчитайте число установленных пакетов, выбрав строки состояния ii из вывода dpkg -l.

Что должно получиться

В журнале работы: вывод команд 1–6, предсказания и объяснения к пунктам 1, 2, 4 и 5. Отдельно ответьте на вопрос: почему dpkg -S /usr/bin/ls не находит пакет, если /bin является ссылкой на /usr/bin?

Часть 2. Ручной запуск приложения

Задание

1. Перейдите в каталог ~/lab-09/lr-env и посмотрите текст app.py командой less app.py. Найдите строки, в которых задаётся порт и код аварийного завершения. Предскажите, какой порт будет использован по умолчанию.
2. Запустите приложение в фоне на порту 8091 (порт 8080 может быть занят другой программой):

cd ~/lab-09/lr-env
APP_PORT=8091 python3 app.py &
sleep 1
curl -s -i http://127.0.0.1:8091/

3. Проверьте, что при обращении к /abc сервер отвечает кодом 200: curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8091/abc.
4. Вызовите аварийное завершение и измерьте код выхода процесса:

APP_PORT=8092 python3 app.py > app.log 2>&1 &
pid=$!
sleep 1
curl -s http://127.0.0.1:8092/crash
echo "код curl: $?"
wait $pid
echo "код выхода: $?"
cat app.log

5. Выполните kill -TERM для процесса, запущенного на порту 8093, и сравните код выхода с кодом из пункта 4.

Что должно получиться

В журнале работы: заголовки ответа на /, код curl при обращении к /crash и причина этого кода, код выхода приложения при падении и при SIGTERM. Объясните, почему код 143 отличается от кода 3 и какие из этих завершений systemd сочтёт аварийными. Подсказка: таблица в документации systemd.service, колонка «Clean exit».

Часть 3. Юнит-файл службы

Задание

1. Скопируйте шаблон и отредактируйте его:

cd ~/lab-09/lr-env
cp templates/app.service app.service

2. Откройте app.service в редакторе и замените значения User=, WorkingDirectory= и путь в ExecStart= на свои: имя пользователя и каталог /home/ваше_имя/lab-09/lr-env. Строки, начинающиеся с #, — комментарии, и их можно не менять.
3. Проверьте файл командой systemd-analyze verify app.service. Вывод может содержать предупреждения о файлах других пакетов (например, snapd.service); отличите их по пути в начале строки.
4. Запишите в журнал работы назначение каждой директивы файла. Опишите, почему User= задан явно, и что будет, если его убрать.

Задание 3.5. Найти и исправить ошибку

Файл broken.service содержит две ошибки. Первая найдена командой systemd-analyze verify broken.service и выводит предупреждение о неизвестном ключе. Вторая командой verify не видна: её можно найти, предсказав, в каком каталоге systemd выполнит ExecStart, и сравнив с расположением app.py.

1. Выполните systemd-analyze verify broken.service. Опишите первую ошибку: строка, секция, почему систему не устраивает.
2. Предскажите, какой каталог получит процесс, запущенный из broken.service без WorkingDirectory=. Проверьте значение по документации: man systemd.exec, поиск WorkingDirectory.
3. Исправьте файл broken.service и сохраните исправленную версию как fixed.service. Повторите verify и убедитесь, что предупреждений о broken-ошибках нет.

Что должно получиться

Файл app.service с вашими значениями и записи в журнале работы по пункту 4. Исправленный fixed.service и краткое описание двух ошибок: что было написано, что произойдёт и как исправлено. Обратите внимание: проверка verify не нашла вторую ошибку, и это важный вывод о пределах статической проверки.

Часть 4. Установка службы и автозапуск

Задание

1. Установите юнит-файл в системный каталог и перечитайте конфигурацию systemd (команды требуют sudo):

sudo cp app.service /etc/systemd/system/app.service
sudo systemctl daemon-reload

2. Предскажите, что покажет systemctl is-enabled app до включения автозапуска. Проверьте.
3. Включите автозапуск и сразу запустите службу, затем проверьте состояние:

sudo systemctl enable --now app
systemctl status app --no-pager
curl -s http://127.0.0.1:8080/

4. Найдите в каталоге /etc/systemd/system/multi-user.target.wants/ ссылку на app.service командой ls -l. Объясните, что означает эта ссылка и почему её создала команда enable, а не start.
5. Остановите службу командой sudo systemctl stop app, затем запустите снова командой sudo systemctl start app. Объясните, чем start отличается от enable.

Пример вывода для пункта 3 (у вас получится свой вывод):

● app.service - Учебный HTTP-сервис лабораторной работы 9
     Loaded: loaded (/etc/systemd/system/app.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-12 10:02:11 MSK; 3s ago
   Main PID: 4120 (python3)
      Tasks: 2 (limit: 9292)
     Memory: 14.0M
     CGroup: /system.slice/app.service
             └─4120 /usr/bin/python3 /home/student/lab-09/lr-env/app.py

Что должно получиться

В журнале работы: вывод systemctl is-enabled до и после, вывод systemctl status app с пояснением каждой строки Loaded, Active, Main PID, ответ curl на /, пояснение разницы между start и enable. Укажите, на каком порту работает служба и почему эта строка находится в шаблоне (Environment=APP_PORT=8080).

Часть 5. Падение службы и перезапуск

Задание

1. Зафиксируйте номер главного процесса службы: systemctl show -p MainPID app. Предскажите, что произойдёт с номером процесса после вызова /crash: останется ли он прежним?
2. Вызовите аварийное завершение службы:

curl -s http://127.0.0.1:8080/crash
sleep 3
systemctl show -p MainPID app
systemctl status app --no-pager

3. Прочитайте записи журнала службы за последние минуту:

journalctl -u app --since "1 min ago" --no-pager

4. Объясните по журналу, что произошло в порядке времени: завершение процесса с кодом 3, ожидание, новый запуск. Сверьте интервал между записями с директивой RestartSec.
5. Остановите службу командой sudo systemctl stop app и посмотрите журнал ещё раз. Появилась ли новая попытка запуска? Объясните, почему systemctl stop не вызывает перезапуска.

Пример вывода для пункта 3 (составлен по образцу журнала systemd, в этой работе не получен дословно; ваши строки могут отличаться):

Oct 12 10:03:40 host python3[4120]: 2026-10-12 10:03:40,512 ERROR получен запрос /crash: аварийное завершение с кодом 3
Oct 12 10:03:40 host systemd[1]: app.service: Main process exited, code=exited, status=3/n/a
Oct 12 10:03:40 host systemd[1]: app.service: Failed with result 'exit-code'.
Oct 12 10:03:42 host systemd[1]: app.service: Scheduled restart job, restart counter is at 1.
Oct 12 10:03:42 host systemd[1]: Stopped Учебный HTTP-сервис лабораторной работы 9.
Oct 12 10:03:42 host systemd[1]: Started Учебный HTTP-сервис лабораторной работы 9.

Обратите внимание на номер процесса: после перезапуска MainPID стал другим, что подтверждает запуск нового процесса.

Что должно получиться

В журнале работы: номера процесса до и после падения, строки журнала с объяснением каждой из них, интервал между падением и новым запуском в сравнении с RestartSec=2, ответ на вопрос пункта 5. Приложите один фрагмент журнала, на котором видно и падение, и перезапуск.

Часть 6. Поиск в журнале за период

Задание

1. Выведите только записи уровня ошибок err и выше за последние 10 минут:

journalctl -u app -p err --since "10 min ago" --no-pager

Предскажите, какие строки приложения попадут в этот вывод: только INFO или также ERROR? Проверьте. Объясните, почему фильтр -p определяет уровень записи, а не её текст. Строки приложения, записанные через log.info, в фильтр -p err не попадают; строки, записанные через log.error, попадают, потому что app.py под systemd начинает их с префикса <3>. Найдите это место в app.py и объясните, что увидел бы фильтр без префикса (подсказка: весь stderr службы journald по умолчанию записывает с уровнем info).

Пример вывода (составлен по документации journald, ваши строки будут отличаться временем и номером процесса):

Oct 12 10:03:40 host python3[4120]: 2026-10-12 10:03:40,512 ERROR получен запрос /crash: аварийное завершение с кодом 3

2. Выведите последние 20 записей службы в коротком формате и подсчитайте число перезапусков, отобрав строки, содержащие Scheduled restart job, через конвейер с grep (тема 6):

journalctl -u app -n 20 -o short --no-pager | grep -c "Scheduled restart job"

3. Определите номер текущей загрузки командой journalctl --list-boots и выведите записи этой загрузки, относящиеся к app, с помощью опции -b 0.
4. Выберите один фрагмент журнала за интервал, в котором зафиксировано падение, и опишите его в журнале работы: время, уровень, программа, сообщение.

Что должно получиться

В журнале работы: команды 1–3 с выводом, число перезапусков (ответ в виде числа), описание фрагмента из пункта 4. Объясните разницу между фильтром -p err и поиском по тексту.

Часть 7 (продвинутая). Ограничение частоты перезапусков

Задание

Продвинутая часть посвящена поведению systemd при частых сбоях. Добавьте в секцию [Unit] файла app.service директивы StartLimitIntervalSec=60 и StartLimitBurst=2. Смысл: не более двух запусков за 60 секунд; при превышении systemd перестаёт перезапускать службу.

1. Предскажите, что произойдёт при трёх подряд вызовах /crash: сколько перезапусков будет выполнено и каким будет итоговое состояние службы. Подсказка: первый запуск тоже входит в счёт StartLimitBurst, поэтому предел может сработать раньше третьего вызова; тогда третий curl получит отказ соединения (код 7), и это тоже нужно объяснить.
2. Внесите изменения, выполните sudo systemctl daemon-reload, запустите службу и выполните три вызова /crash с паузой 3 секунды между ними. Проверьте состояние командой systemctl status app.
3. Найдите в журнале запись о достижении предела перезапусков (start-limit-hit или сообщение о превышении частоты) командой journalctl -u app -n 30 --no-pager.
4. Сбросьте счётчик командой sudo systemctl reset-failed app и запустите службу вручную. Объясните, почему состояние failed не исчезает само собой и что означает reset-failed.
5. Объясните в журнале работы, почему в реальной эксплуатации неограниченные перезапуски опасны, и какое значение StartLimitBurst выбрал бы администратор для службы с базой данных.

Что должно получиться

В журнале работы: результаты пунктов 1–5, итоговый файл app.service с добавленными директивами, выводы systemctl status до и после предела перезапусков, одна строка журнала о достижении предела и объяснение.

Часть 8 (продвинутая). Ротация журнала приложения

Задание

Часть выполняется без sudo и без systemd: приложение запускается вручную, а журнал пишется в файл.

1. Запустите приложение так, чтобы журнал шёл в файл: APP_PORT=8091 python3 app.py 2>>app.log & echo $! > app.pid. Выполните три запроса curl -s http://127.0.0.1:8091/ и посмотрите cat app.log. Почему здесь 2>>, а не 2>?

2. Создайте app-logrotate.conf для файла app.log (абсолютный путь, например $PWD/app.log) с директивами daily, rotate 3, compress, delaycompress, missingok, notifempty, copytruncate. Проверьте: logrotate -d -s state app-logrotate.conf. Запишите решение logrotate (при daily и свежем файле состояния оно может быть «ротация не нужна») и объясните, зачем дальше нужен ключ -f.

3. Предскажите содержимое каталога после logrotate -s state -f app-logrotate.conf, выполните команду и сравните с ls -l. Сделайте ещё один запрос curl, повторите принудительную ротацию дважды и найдите, в каком файле лежит каждая запись (cat, zcat). Объясните, почему app.log.1 не сжат, а app.log.2.gz сжат. Откройте cat state.

4. Найдите и исправьте ошибки. Выполните sed "s|ПУТЬ|$PWD|" broken-logrotate.conf > my-logrotate.conf и разберите конфиг с -d. В нём три ошибки: значение rotate, имя файла и сигнал в postrotate. Первые две logrotate -d покажет сообщениями (bad rotation count и does not exist -- skipping), третью — только практика: исправьте первые две и выполните logrotate -s state2 -f my-logrotate.conf при запущенном приложении (PID в app.pid). Что произошло с приложением и какой строкой это отражено в выводе оболочки? Замените postrotate на copytruncate, перезапустите приложение, повторите ротацию и убедитесь, что приложение живо (curl), а запись попала в app.log.

5. Предскажите и проверьте: journalctl --disk-usage и SystemMaxUse= в /etc/systemd/journald.conf. Если systemd недоступен, запишите по теории, какой командой освободить место и какую директиву задать для постоянного предела. Завершите приложение: kill $(cat app.pid).

6. Выполните timedatectl и hostnamectl. Если systemd недоступен (WSL2 без настройки), запишите текст ошибки и получите те же сведения командами date, date -u, cat /etc/timezone, ls -l /etc/localtime, hostname.

Что должно получиться

В журнале работы: содержимое app.log и ls -l до и после ротации, перечень файлов с объяснением delaycompress, исходные и исправленные строки my-logrotate.conf с объяснением трёх ошибок, вывод logrotate -d, показавший ошибки, а также сравнение postrotate с сигналом и copytruncate. Запись о том, чем заменены timedatectl и hostnamectl в вашей среде.

Журнал работы

Для себя ведите записи в порядке «предсказание — команда — фактический вывод — объяснение расхождения». Выводы команд сохраняйте полностью, а не пересказывайте. В конце отметьте, что оказалось неожиданным и как вы это проверили.

Контрольные вопросы

1. Чем APT отличается от dpkg? Какой из них обращается к репозиторию, а какой работает только с локально распакованными пакетами?
2. Почему apt-get -s install не требует прав root, а apt install требует?
3. Что означают строки Installed и Candidate в выводе apt-cache policy?
4. Почему dpkg -S /usr/bin/ls не находит пакет, хотя /bin/ls принадлежит coreutils? Какое свойство системы здесь проявляется?
5. Что означает пустой ответ dpkg -S /etc/passwd с кодом возврата 1 и как узнать, кто создал такой файл?
6. Почему директива Restart=on-failure не перезапускает службу после systemctl stop?
7. Для чего нужен WantedBy=multi-user.target и что создаёт команда enable?
8. Почему относительный путь к скрипту в ExecStart приводит к ошибке, хотя python3 без пути работает?
9. Чем systemctl start отличается от systemctl enable --now?
10. Какие из перечисленных сигналов и кодов выхода systemd считает чистым завершением, а при каких Restart=on-failure перезапускает службу?
11. Какой фильтр journalctl выберет только ошибки, а какой — записи последнего часа? Как объединить оба фильтра?
12. Почему в WSL2 без systemd команда systemctl status не работает, а dpkg и apt-cache работают? Что нужно изменить в /etc/wsl.conf?
13. Зачем нужна ротация файловых журналов? Что означают rotate 3, compress и delaycompress?
14. Почему после обычной ротации программа продолжает писать в app.log.1? Какие есть два способа это исправить и в чём недостаток каждого?
15. Как проверить конфигурацию logrotate и выполнить ротацию без root? Что хранится в файле состояния?
16. Кто запускает logrotate в Ubuntu и как ограничивается размер журнала journald?