Теория: Init-системы: systemd и не только

Когда ядро завершает загрузку и монтирует корневую файловую систему, оно должно передать управление пользовому пространству - процессам и службам. Первым процессом, который запускается, становится init (его PID всегда равен 1).

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

То, как именно устроена init-система, определяет скорость загрузки, стабильность и предсказуемость всей операционной системы. В старых UNIX-системах это был классический sysvinit — набор последовательных скриптов /etc/init.d. Современные Linux-дистрибутивы перешли на systemd — более быструю и гибкую систему, где процессы запускаются параллельно, а зависимости описываются декларативно через юниты.

От SysVinit к Upstart

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

Первая и долгое время единственная система инициализации в Linux — SysVinit. Она пришла из Unix System V и работала через обычные shell-скрипты в каталоге /etc/init.d. Для разных режимов работы существовали каталоги /etc/rc*.d, где лежали символические ссылки на эти скрипты. Каждый режим — или «уровень выполнения» — соответствовал определённому состоянию системы: однопользовательскому, многопользовательскому, графическому. При старте init выбирал нужный уровень и запускал все скрипты подряд, по их номерам в названии.

Эта схема была проста и надёжна, но со временем стала узким местом. Все процессы запускались строго последовательно — пока один не закончит работу, другой не начинался. Никаких зависимостей между службами не учитывалось, из-за чего, например, сетевые демоны могли стартовать до того, как появлялась сама сеть. В итоге система загружалась медленно, а init не мог контролировать запущенные процессы и перезапускать их при сбое.

Чтобы решить эти проблемы, компания Canonical создала новую систему инициализации — Upstart. Она появилась в середине 2000-х и стала первым серьёзным шагом к современным моделям управления процессами. Вместо фиксированных уровней выполнения Upstart использовал событийный подход. Службы запускались не по жёсткому списку, а в ответ на конкретные события: появление сети, монтирование файловой системы, завершение загрузки ядра.

Такой подход позволил системе стартовать гораздо быстрее — процессы больше не ждали друг друга. Демоны могли запускаться параллельно, а конфигурация стала гибче: можно было описать, что именно должно произойти перед запуском или остановкой службы. Однако Upstart всё ещё оставался компромиссом. Он по-прежнему полагался на shell-скрипты и не обеспечивал полного контроля над зависимостями и состояниями служб. Кроме того, разные дистрибутивы реализовывали события по-разному, что усложняло поддержку.

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

Systemd: современный стандарт

После Upstart Linux-сообщество столкнулось с необходимостью более фундаментальных изменений. Системе инициализации нужно было не просто запускать процессы параллельно, а управлять всем жизненным циклом служб — с зависимостями, событиями, журналом и безопасностью. Ответом стала systemd, разработанная Леннартом Поттерингом и Кейем Сиверсом.

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

Главное отличие systemd в том, что она запускает службы параллельно и понимает зависимости между ними. Если службе нужен доступ к сети или файловой системе, systemd не просто ждёт, а отслеживает, когда появится нужное условие, и только тогда запускает процесс. Это делает загрузку гораздо быстрее и надёжнее.

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

Файлы юнитов хранятся в каталогах /etc/systemd/system (пользовательские настройки) и /lib/systemd/system (системные). Самый распространённый тип — .service, он описывает службы, например сетевые демоны или веб-серверы. Но есть и другие типы: .socket для сетевых соединений, .mount для файловых систем, .timer для периодических задач и .target — для объединения нескольких юнитов в одно состояние системы.

Таргеты в systemd заменили старые уровни выполнения (runlevels). Например, multi-user.target соответствует многопользовательскому режиму без графики, а graphical.target добавляет графическую оболочку. Система просто активирует нужный таргет, и вместе с ним запускаются все связанные службы.

Systemd также ведёт централизованный журнал — journald, который собирает логи всех процессов. Это избавляет от множества разрозненных лог-файлов и позволяет быстро анализировать работу системы.

В итоге systemd объединила под одним управлением десятки отдельных механизмов, сделав Linux быстрее, предсказуемее и управляемее. Это уже не просто процесс PID 1, а центр всей операционной системы, который знает, какие службы активны, какие зависят друг от друга и как безопасно остановить или перезапустить любую из них.

Основные команды systemd

После того как systemd стала основной системой инициализации, у неё появился свой универсальный инструмент управления — команда systemctl. Через неё можно делать всё: запускать и останавливать службы, включать или отключать автозагрузку, проверять состояние процессов, а также управлять целыми режимами работы системы.

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

Например, чтобы запустить службу nginx, достаточно одной команды:

sudo systemctl start nginx

Она мгновенно активирует юнит nginx.service и все его зависимости. Если нужно, чтобы веб-сервер автоматически запускался при каждой загрузке, добавляется параметр enable:

sudo systemctl enable nginx

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

sudo systemctl status nginx

Она покажет, активна ли служба, когда она была запущена, сколько времени работает и есть ли ошибки в журнале.

Такая модель полностью заменила старые утилиты вроде service, chkconfig и init.d. Всё теперь делается через единый интерфейс systemctl, независимо от того, какую службу вы запускаете — ssh, docker или любой другой демон.

Кроме управления отдельными процессами, systemctl позволяет переключать состояния системы, которые в systemd называются таргетами. Например, чтобы перейти в режим восстановления, где запускаются только базовые службы и доступен root-доступ, используется команда:

sudo systemctl isolate rescue.target

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

Текущий режим можно проверить:

systemctl get-default

Эта команда покажет, какой таргет используется по умолчанию — обычно это graphical.target на настольных системах или multi-user.target на серверах. Если нужно изменить его, например, чтобы система загружалась сразу в консоль без графического интерфейса, используется команда:

sudo systemctl set-default multi-user.target

Теперь при следующем запуске systemd начнёт работу в указанном режиме.

Systemctl стал центральным инструментом администрирования Linux. Он объединил управление службами, автозагрузкой и состояниями системы в один понятный интерфейс, где каждая команда логично связана с остальными. Благодаря этому systemd не только ускоряет работу, но и делает управление системой предсказуемым и прозрачным.

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

journalctl -b        # логи текущей загрузки
journalctl -u ssh    # история конкретной службы
journalctl -f        # поток новых сообщений в реальном времени

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